FAPI part 2 - Request Object Endpoint (client authentication)
The Request Object Endpoint is basically a protected endpoint at the AS/OP utilized to push request objects up front to the AS/OP. I like the idea as it moves the burden for managing request objects to the AS.
The endpoint uses a digital signature as mechanism to authenticate the client, which completely differs from the way clients are authenticated at AS endpoints or standard OAuth resource servers.
From an implementers perspective, this means the endpoint needs to know the client_ids and respective public keys of all clients entitled to use the endpoint. I expect this to make the implementation more complex than needed.
I suggest to make it a standard OAuth resource and use (cert-bound) access tokens issued based on the client credentials (or any appropriate grant type) to protect it. This way, all standard OAuth mechanisms can be leveraged to implement the endpoint. The endpoint could be even implemented as an extension to OAuth/OpenID products without any extension points or access to internal data.
Comments (13)
-
-
Would not that actually add an additional round trip? When it was discussed back in the time this clause was added, people felt that pre-steps that are necessary for making such an endpoint a regular OAuth endpoint is unnecessary. You are making the signed request object anyways for this case. Then, is it not even easier to just POST it to a REST URL than to do an OAuth protected API call? From the client's perspective, it should certainly be easier to just do a POST.
From the AS's point of view, it knows the client_id -- public_key binding necessarily. Otherwise, a request object will fail. So this is not an additional requirement. Whether supporting this endpoint or not, the AS need to be able to do this validation.
If you make this endpoint a regular OAuth protected API, then, you would have to
- Create a client credential grant based authorization endpoint which supports client-cert based client authentication;
- Issue and manage access and refresh token for that client_id for this endpoint that is bound to the client's cert;
- Upon receiving the request object by POST,
- validate the sender constrained access token using MTLS;
- do the request object signature validation; and
- Return the response.
In contrast to this, the current proposal just requires the AS to
- Upon receiving the request object by POST,
- do the request object signature validation; and
- Return the response.
It seems the current proposal is much more simple.
-
- changed status to open
-
reporter it would add another roundtrip, but (I assume) it would be easier to implement on both ends. Let me explain:
From what I understand, you want the client to „deposit“ the request object with the AS and later use it in the authorization process. The AS authenticates the client by verifying the signature. Does it verify the signature again, when the request_uri is sent as part of the authorization request? Or more precisely: would you assume the request object to be treated the same way as externally hosted request objects?
I wouldn’t since processing can be optimized very much.
Once the AS received the request object, it can store it in an internal representation, referred to by the dynamic part of the URN the spec defines. So no need to re-evaluate the already checked request object.
If we agree on this then there is basically no longer a need to sign the request object. Remember: this was originally done to prevent modifications on transit and to authenticate the client on the receiving end of a redirect.
Here we are facing a different situation: AS and client communicate via a mTLS protected connection and can authenticate each other directly.
I think a client can easier authenticate towards the AS using client credentials, as this is very similar to the way it anyway authenticates when performing the code exchange. And from an AS implementation perspective, it would be acceptable to share client ids and certificates and permissions across my endpoints. But it’s better if this is not required. This also allows teams building on top of a commercial product to add the new endpoint ob their own without the need to access the AS client data via proprietary interfaces.
-
I'm still gathering my thoughts on the whole question raised here, but I have one particular insight right now:
If we agree on this then there is basically no longer a need to sign the request object. Remember: this was originally done to prevent modifications on transit and to authenticate the client on the receiving end of a redirect.
A signed request object can also be used for non-repudiation. eg. a bank can potentially use it to prove that a TPP did or didn't request strong customer authentication.
-
I can see benefits of both approaches. Its worth considering what the current draft of jwsreq says:
(d) Authorization Server is providing an endpoint that provides a Request Object URI in exchange for a Request Object. In this case, the Authorization Server MUST perform Client Authentication to accept the Request Object and bind the Client Identifier to the Request Object URI it is providing. Since Request Object URI can be replayed, the lifetime of the Request Object URI MUST be short and preferably one-time use. The entropy of the Request Object URI MUST be sufficiently large. The adequate shortness of the validity and the entropy of the Request Object URI depends on the risk calculation based on the value of the resource being protected. A general guidance for the validity time would be less than a minute and the Request Object URI is to include a cryptographic random value of 128bit or more at the time of the writing of this specification.
Essentially we just wanted to define that endpoint.
-
reporter there is a link to issue
#142 -
Separate document? Related to the document that Torsten et al are working on right now. To be dealt with after that discussion.
-
reporter I'm leaning towards a separate document and would also recommend to bring it to the IETF asap. It's a natural companion of JAR.
-
- changed component to Pushed Request Uri
The Request Object Endpoint is basically a protected endpoint at the AS/OP utilized to push request objects up front to the AS/OP. I like the idea as it moves the burden for managing request objects to the AS.
The endpoint uses a digital signature as mechanism to authenticate the client, which completely differs from the way clients are authenticated at AS endpoints or standard OAuth resource servers.
From an implementers perspective, this means the endpoint needs to know the client_ids and respective public keys of all clients entitled to use the endpoint. I expect this to make the implementation more complex than needed.
I suggest to make it a standard OAuth resource and use (cert-bound) access tokens issued based on the client credentials (or any appropriate grant type) to protect it. This way, all standard OAuth mechanisms can be leveraged to implement the endpoint. The endpoint could be even implemented as an extension to OAuth/OpenID products without any extension points or access to internal data.
-
reporter I added a first version of the new pushed request object draft to the repo.
https://bitbucket.org/openid/fapi/src/pushed_request_uri/Financial_API_Pushed_Request_Object.md
-
-
assigned issue to
The Request Object Endpoint is basically a protected endpoint at the AS/OP utilized to push request objects up front to the AS/OP. I like the idea as it moves the burden for managing request objects to the AS.
The endpoint uses a digital signature as mechanism to authenticate the client, which completely differs from the way clients are authenticated at AS endpoints or standard OAuth resource servers.
From an implementers perspective, this means the endpoint needs to know the client_ids and respective public keys of all clients entitled to use the endpoint. I expect this to make the implementation more complex than needed.
I suggest to make it a standard OAuth resource and use (cert-bound) access tokens issued based on the client credentials (or any appropriate grant type) to protect it. This way, all standard OAuth mechanisms can be leveraged to implement the endpoint. The endpoint could be even implemented as an extension to OAuth/OpenID products without any extension points or access to internal data.
-
assigned issue to
-
reporter - changed status to resolved
duplicates
#253that was recently resolved - Log in to comment
from an implementer's POV I second this proposal