recommend auth code flow using signed requests - reloaded

[AxelNennker]

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

This PR recommends using signed OIDC authoritzation code flow requests.

@mhfoo @garciasolero @sebdewet @eric-murray @shilpa-padgaonkar

Which issue(s) this PR fixes:

Fixes #205

additional context

new version of the merged #226 after reverting the merge

[AxelNennker]

Regarding @jpengar 's comment #226 (comment)

And in the CAMARA profile document, in the case of CIBA, there is not even a mention of the aud parameter for the signed authentication request.

The CIBA section in the profile does not mention "aud" but is does not need to because "aud" is defined in the client credentials section and all CIBA request must be authenticated using client credentials.

This document RECOMMENDS that for OIDC Authorization Code Flow and OAuth2 Client Credentials Grant the audience SHOULD be the URL of the Authorization Server's Token Endpoint. This document RECOMMENDS that for OIDC CIBA the audience SHOULD be the Backchannel Authentication Endpoint.

[jpengar]

Regarding @jpengar 's comment #226 (comment)

And in the CAMARA profile document, in the case of CIBA, there is not even a mention of the aud parameter for the signed authentication request.

The CIBA section in the profile does not mention "aud" but is does not need to because "aud" is defined in the client credentials section and all CIBA request must be authenticated using client credentials.

This document RECOMMENDS that for OIDC Authorization Code Flow and OAuth2 Client Credentials Grant the audience SHOULD be the URL of the Authorization Server's Token Endpoint. This document RECOMMENDS that for OIDC CIBA the audience SHOULD be the Backchannel Authentication Endpoint.

I may not have explained myself well enough, but I think you are missing the point I was trying to make with my comment in #226. Also, be careful not to mix up the client credentials grant, the client authentication methods and signed authentication requests.

[AxelNennker]

I may not have explained myself well enough, but I think you are missing the point I was trying to make with my comment in #226. Also, be careful not to mix up the client credentials grant, the client authentication methods and signed authentication requests.

Let's take a step back and talk about this PR which says:

It is RECOMMENDED that the value of the aud field of the signed authentication request is the URL of the Authorization Endpoint

The Authorization Endpoint is the endpoint where the signed authentication request is sent to, right?
So, the recommendation follows the recommendation from RFC9101 which says "put in aud the url of the endpoint you send the request to".

It is RECOMMENDED by this specification to use this practice for the following endpoints defined in [RFC6749], [RFC6750], and [RFC8414]:
(a) Protected resources (protected_resources)
(b) Authorization endpoint (authorization_endpoint)
(c) Redirection URI (redirect_uri)
(d) Token endpoint (token_endpoint)

So, for this PR we are in option (b).
Put together the recommendation of rfc9101 is:

it is a good practice to explicitly state the intended interaction endpoints and the message position in the sequence in a tamper-evident manner so that the intent of the initiator is unambiguous.

The intended interaction endpoint relevant for this PR is the authorization_endpoint and this PR "explicitely states" its intention by putting that URL into aud.

Maybe you could write create a review and write a suggestion? I think this PR follows the recommendation of RFC9101.

---

No, I am not mixing Client Authentication with Client Credentials Grant. I think there we are following the recommendation of RFC9101 and in this PR we do so as well.

[jpengar]

No, I am not mixing Client Authentication with Client Credentials Grant. I think there we are following the recommendation of RFC9101 and in this PR we do so as well.

Well, when you read this sentence, it looks like a few things got mixed up.

The CIBA section in the profile does not mention "aud" but is does not need to because "aud" is defined in the client credentials section and all CIBA request must be authenticated using client credentials.

First, you say "Client Credentials" section, which points to a section called "Client Authentication", so the naming thing could be misleading, as there is another section called "Client Credentials Flow", which is intended to describe definitions for Client Credentials Grant.

Then you say that in CIBA there is no need to specify anything about aud because it is defined in the Client Credentials section (referring to the Client Authentication section). But those definitions refer to the definition of aud for the client_assertion, which is NOT the signed request object assertion. The same definitions do not necessarily apply to the signed request object unless the profile explicitly says so. And that will lead us to have same aud value for different assertions which is something that we want to avoid as described by @mhfoo here

Use different "aud" values for different uses of JWTs from the same issuer. Then audience validation will reject JWTs substituted into inappropriate contexts.

So when in CIBA, the profile says nothing about the aud for the signed object request. A profile reader should just go to the CIBA standard as the profile does not define anything on top of it for signed request objects. And if you look at the CIBA standard, it says that the aud claim MUST contain the value of the Issuer Identifier for the OP, which identifies the Authorisation Server as the intended audience.

Will we then define a different aud value for the signed request object in Auth Code Flow and CIBA?

[jpengar]

I may not have explained myself well enough, but I think you are missing the point I was trying to make with my comment in #226. Also, be careful not to mix up the client credentials grant, the client authentication methods and signed authentication requests.

Let's take a step back and talk about this PR which says:

It is RECOMMENDED that the value of the aud field of the signed authentication request is the URL of the Authorization Endpoint

The Authorization Endpoint is the endpoint where the signed authentication request is sent to, right? So, the recommendation follows the recommendation from RFC9101 which says "put in aud the url of the endpoint you send the request to".

It is RECOMMENDED by this specification to use this practice for the following endpoints defined in [RFC6749], [RFC6750], and [RFC8414]:
(a) Protected resources (protected_resources)
(b) Authorization endpoint (authorization_endpoint)
(c) Redirection URI (redirect_uri)
(d) Token endpoint (token_endpoint)

So, for this PR we are in option (b). Put together the recommendation of rfc9101 is:

it is a good practice to explicitly state the intended interaction endpoints and the message position in the sequence in a tamper-evident manner so that the intent of the initiator is unambiguous.

The intended interaction endpoint relevant for this PR is the authorization_endpoint and this PR "explicitely states" its intention by putting that URL into aud.

So are we going to ignore what RFC9101 says in section 4 "Request Object" in favour of section 10.3 "Explicit Endpoints"? You never say anything about that, because the Request Object section in RFC9101 says:

To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a JWS-signed JWT [RFC7519]. If signed, the Authorization Request Object SHOULD contain the Claims iss (issuer) and aud (audience) as members with their semantics being the same as defined in the JWT [RFC7519] specification. The value of aud should be the value of the authorization server (AS) issuer, as defined in RFC 8414 [RFC8414].

And will we also ignore OIDC Specification Section 6.1 "Passing a Request Object by Value" in favour of section 10.3 "Explicit Endpoints" of RFC9101? It says the following:

The Request Object MAY be signed or unsigned (unsecured). When it is unsecured, this is indicated by use of the none algorithm [JWA] in the JOSE Header. If signed, the Request Object SHOULD contain the Claims iss (issuer) and aud (audience) as members. The iss value SHOULD be the Client ID of the RP, unless it was signed by a different party than the RP. The aud value SHOULD be or include the OP's Issuer Identifier URL.

I could be wrong, of course, so let me know...

[AxelNennker]

RFC9101 seems not to be very consistent.
I am referring to RFC9101 Security Considerations https://www.rfc-editor.org/rfc/rfc9101.html#name-explicit-endpoints that the endpoint should be explicitly named. I interpret "explicitly named" as meaning the "aud" field.

I think that is not ignoring RFC9101 but following the stronger advice from the RFC9101 Security Considerations.
The weaker definition in RFC9101 is this

The value of aud should be the value of the authorization server (AS) issuer, as defined in RFC 8414 [RFC8414].

There the issuer could be for example https://issuer.example.org/

The advise from the RFC9101 security consideration advises to explicitly name the endpoint.
When the client assertion is send to the token endpoint then the aud value is the token endpoint url.
The PR follows the RFC9101 security considerations and recommends that the value of aud is the endpoint the authentication request is sent to. E.g. aud=https://oidccode.example.org/

Example RFC8114 metadata:
{
"issuer": "https://issuer.example.org/",
"authorization_endpoint": "https://codeoidc.example.org/ ",
"token": "https://tokenoidc.example.org",
}

In the Client Authentication section we follow that security advice.
And the current text in this PR follows the stronger security section advise.

If all assertions, whether they are used for Client Credentials Grant or Signed Request Object used "issuer" from the server's metadata then a mixup is more likely. Therefore in Client Authentication we defined the explicit endpoint to be used. This PR does the same.

I would not call that "ignoring". CAMARA deliberately RECOMMENDS the more secure option.

[jpengar]

@AxelNennker @mhfoo @garciasolero @sebdewet @eric-murray @shilpa-padgaonkar Considering all the arguments and explanations, we at Telefónica will accept the existing text for the aud and sub claims. We are only proposing now one change to the current text to make us feel comfortable in approving the PR on our side. Change the reference to RFC9101 instead of OIDC.

[jpengar]

LGTM

[sebdewet]

LGTM