FAPI part 2 - Request Object Endpoint (client authentication)

Issue #160 resolved
Torsten Lodderstedt created an issue

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)

  1. Nat Sakimura

    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

    1. Create a client credential grant based authorization endpoint which supports client-cert based client authentication;
    2. Issue and manage access and refresh token for that client_id for this endpoint that is bound to the client's cert;
    3. Upon receiving the request object by POST,
    4. validate the sender constrained access token using MTLS;
    5. do the request object signature validation; and
    6. Return the response.

    In contrast to this, the current proposal just requires the AS to

    1. Upon receiving the request object by POST,
    2. do the request object signature validation; and
    3. Return the response.

    It seems the current proposal is much more simple.

  2. Torsten Lodderstedt 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.

  3. Joseph Heenan

    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.

  4. Dave Tonge

    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.

  5. Nat Sakimura

    Separate document? Related to the document that Torsten et al are working on right now. To be dealt with after that discussion.

  6. Torsten Lodderstedt 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.

  7. Dave Tonge

    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.

  8. Nat Sakimura

    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.

  9. Log in to comment