Client authentication at pushed request URI endpoint

[Torsten Lodderstedt]

Brian raised the following question:

is there really value in allowing for the signature on the JWT to take place of client authentication? I understand that it can work that way but it means that client authentication at the endpoint has to behave differently conditional on the content-type of the request, which feels awkward and unnecessarily complex. It seems like it'd be more straightforward to just have client authentication at this endpoint work the same as it does for other endpoints to which the client makes direct requests (noting that none is a valid client auth method for public clients). Note that making this change would impact several other places in the document.

[Tom Jones]

It sounds like you are confusing authorization with authentication. It is common for authorization to be content dependent.

[Torsten Lodderstedt]

Can you please explain how you came to your conclusion? My comment (on behalf of Brian) compares (direct) client authentication (e.g. based on mTLS) and use of a signature for client authentication. Where is the authorization piece?

[Takahiko Kawasaki]

I created #253 (Pushed Request Object - Signed request object shouldn't be used for client authentication) without knowing this issue (#226) has already been created.

I agree with Torsten. The request object itself should not be used for client authentication. Details are written in #253.

[Takahiko Kawasaki]

Because the Content-Type of a request to the request object endpoint is application/jwt or application/json and not application/x-www-form-urlencoded, request parameters related to client authentication (client_id, client_secret, client_assertion and client_assertion_type) need to be embedded in the payload part of the request object.

This is different from the design of “Signed Authentication Request” of CIBA Core. In CIBA, request parameters to the backchannel authentication endpoint can be packed into a JWT and passed to the endpoint as the value of the request request parameter. However, request parameters related to client authentication must be outside the JWT.

• CIBA Issue 117 : CIBA: other request parameters when "request" is present
• CIBA Issue 128 : ambiguities in 7.1.1 signed authentication request

I'd like to confirm we are on the same page. When the client authentication method is assertion-based (client_secret_jwt or private_key_jwt), client_assertion and client_assertion_type are embedded in the payload part of the request object like below.

{  
   "response_type":"code",
   "client_id":"s6BhdRkqt3",
   "client_assertion": "{CLIENT-ASSERTION}",
   "client_assertion_type":
     "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
   "redirect_uri":"https://client.example.org/cb",
   "scope":"accounts",
   "state":"af0ifjsldkj",
   "code_challenge_method":"S256",
   "code_challenge":"5c305578f8f19b2dcdb6c3c955c0a...97e43917cd"
}

However, there is room for discussion for client_secret_post. There would be two options. One option is to prohibit client_secret_post. The other option is to embed client_secret_post in the payload like below.

{  
   "response_type":"code",
   "client_id":"s6BhdRkqt3",
   "client_secret": "{CLIENT-SECRET}",
   "redirect_uri":"https://client.example.org/cb",
   "scope":"accounts",
   "state":"af0ifjsldkj",
   "code_challenge_method":"S256",
   "code_challenge":"5c305578f8f19b2dcdb6c3c955c0a...97e43917cd"
}

At least, I'd like to reach a consensus on client_secret_post.

[Torsten Lodderstedt]

every good point. My proposal is to use the BASIC authorization header only for client authentication using client secrets.

Assertion based authentication could be tricky. Potentially, the signed request object would be more handy?

[Joseph Heenan]

I’m not convinced it’s a good idea to start passing client authentication within JSON objects - there’s no precedent for that I’m aware of, so it would mean requiring AS’s to support completely new paths through their client authorization source code, plus for the secret case it greatly exposes the chance that an AS ends up leaking the client secret (it will have to either scrub it from the request object before storing it, or make sure none of it’s code paths end up accidentally revealing any of the content of the object).

The basic conflict is really that using client authentication at an endpoint isn’t compatible with POST body content types other than application/x-www-form-urlencoded. At least by a strict reading it’s not even compatible with https://tools.ietf.org/html/draft-ietf-oauth-mtls-14 which requires client_id to be passed in application/x-www-form-urlencoded.

[Torsten Lodderstedt]

well, then let’s send the request object as parameter of application/x-www-form-urlencoded encoded POST request. That’s basically much more inline with https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12#section-5.1, as it passes the request object as URI request parameter.

[Takahiko Kawasaki]

application/x-www-form-urlencoded and request= parameter will be good. I agree on it. My personal sentiment is that application/json would be easier for RP developers. However, from a technical point of view, if the request object endpoint wants to perform client authentication, application/x-www-form-urlencoded would be the final conclusion.

If we wanted to enable the request object endpoint to accept application/json, we would have to discuss "protection by an initial access token" as is mentioned in RFC 7591 (OAuth 2.0 Dynamic Client Registration Protocol), but it sounds overkilling.

[Takahiko Kawasaki]

The request object endpoint defined in FAPI Part 2 expects application/jws and "7.2. Request" says as follows.

The request object shall be signed for client authentication and as evidence of the client submitting the request object, which is referred to as 'non-repudiation'.

FAPI Part 2 does not say "If the request object is not signed, the client is expected to authenticate itself using its registered token endpoint authentication method." (excerpted from “Pushed Request Object”)

The point which affects the final decision is whether to (1) use the request object itself for client authentication or (2) make the request object endpoint behave in the same way as other endpoints in terms of client authentication.

[Brian Campbell]

I do believe there is tangible value in (2) making the request object endpoint behave in the same way as other endpoints in terms of client authentication. It does unfortunately bring the legacy of application/x-www-form-urlencoded which isn’t the prettiest. But I feel the reuse in concepts and code is worth the trade-off.

[Torsten Lodderstedt]

duplicates #253 that was recently resolved