Request Object or JAR (JWT Secured Authorization Request)

[TakahikoKawasaki]

Request Object defined in OpenID Connect Core 1.0 Section 6 or JAR (JWT Secured Authorization Request) support.

Because Request Object (or JAR) has a considerably big impact on authorization server implementations, it should be designed and implemented from the beginning. Otherwise, it will be required sooner or later to rewrite source codes related to request parameter handling from scratch.

[jgrandja]

@TakahikoKawasaki I agree that a JAR can provide an added level of security for Authentication Requests. I'm curious how widely used this capability is? Do you know of any well-known OIDC providers that have implemented this? If so, can you please provide a link?

Because Request Object (or JAR) has a considerably big impact on authorization server implementations

Can you be more specific on what you mean by "considerably big impact"?

[TakahikoKawasaki]

Financial-grade API (FAPI) Part 2 requires that an authorization request utilize "Request Object" (JAR is a successor of Request Object). This means that at least all of the certified FAPI OPs support Request Object. Open Banking in UK, CDR (Consumer Data Right) in AU, FDX (Financial Data Exchange) in US, and other entities in various countries have adoped / are planning to adopt FAPI. Even open-source implementations that are not listed there support Request Object. Examples are Keycloak and IdentityServer4. These days, it is rather difficult to find authorization server implementations that do not support Request Object.

A naive implementation extracts a request parameter from the query part of the authorization request. On the other hand, authorization server implementations that support Request Object do the following to extract a request parameter.

1. Check if the authorization request contains the request request parameter or the request_uri request parameter.
2. If request_uri is given, the authorization server fetches a request object pointed to by the URI. On the other hand, in the case of request, the value of the request request parameter is a request object.
3. If the request object is encrypted, the authorization server has to decrypt it using an appropriate private key which should be found in the server's JWK Set.
4. If the request_object_encryption_alg client metadata is registered, the authorization server must confirm that the encryption algorithm of the request object matches the registered algorithm.
5. The same thing applies to the request_object_encryption_enc client metadata.
6. Then, if the request object is signed, the authorization server must verify the signature of the request object. For the verification, the authorization server gets the public key that corresponds to the private key used for the signature. The public key can be found in the client's JWK Set. The content of the JWK Set should be registered as the value of the jwks client metadata in the authorization server, or the location of the content should be registered as the value of the jwks_uri. If jwks_uri is registered, the authorization server has to fetch the client's JWK Set from the location. In any case, the authorization server verifies the signature with the public key.
7. If the request_object_signing_alg client metadata is registered, the authorization server must confirm that the signature algorithm of the request object matches the registered algorithm.
8. The authorization server must confirm that various claims in the request object such as iss, aud, exp, nbf, etc. are valid.
9. Finally, the authorization server extracts a request parameter from the request object.
10. When the target request parameter is not found in the request object, the authorization server refers to the corresponding request parameter outside the request object. (Note that JAR prohibits from referring to outside request parameters.)

In addition, FAPI Part 2 imposes additional requirements on request objects. For example, the lifetime of a request object which is computed by exp - nbf must not exceed 60 minutes. Allowed signing algorithms are PS256 and ES256 only. The RSA1_5 encryption algorithm is prohibited.

The reason I said "considerably big impact" is above.

See also "Implementer’s note about JAR (JWT Secured Authorization Request)" for details about differences between OIDC Request Object and JAR.

[jgrandja]

Thank you for the details @TakahikoKawasaki and for your explanation on "considerably big impact".

This makes sense. As briefly mentioned in this comment, we follow a methodical development process so re-writes won't happen.

Another thing to be aware of is that this project is in the spring-projects-experimental org, which allows us to move quicker with feature development and re-factor at-will breaking existing public API's without worrying about deprecation scheduling. We still have a ways to go before this reaches 1.0.0. Rest assured, extension points will be available and we will strive to ensure the framework provides the greatest flexibility possible and is able to adapt to change as we continue to build this out.

I'm curious, are you evaluating this project as a potential base framework for Authlete?

[TakahikoKawasaki]

No, sorry. I'm not evaluating this project. I registered issues (#206 ~ #212) only because I was asked by a Japanese guy to share my knowledge with the Spring community although there was no benefit to me.

[dciarniello]

I'm wondering if there's been any movement on this request. If not, I'd like to add my vote for it to be done as clients are beginning to require support for this functionality.

[sjohnr]

@dciarniello make sure to 👍 the opening post if you are voting for this issue. We frequently view community up-votes as a way to gauge priority from the community's perspective.