Proposal for CAMARA mandated minimum acceptable JWT token lifetime

[eric-murray]

Problem description
CAMARA mandate that clients be authenticated using private_key_jwt. The OIDC code specification mandates that the JWT includes an exp claim. Whilst tokens that have expired must be rejected by the authorisation server, creating long lived tokens (to remove the risk of token expiration) itself leads to potential security risks.

This is recognised by RFC 7523, which states:

... the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future

However, neither RFC 7523 nor OIDC nor CAMARA give any guidance as to what is considered to be "unreasonably far in the future" , or what should be the minimum token lifetime that must be accepted by all authorisation servers. This could lead to a situation where client implementations generate tokens that are accepted by some authorisation servers, but rejected by others, purely because of the token lifetime.

Possible evolution
A minimum JWT token lifetime that must be accepted by all authorisation servers should be mandated by CAMARA. It is proposed that this minimum lifetime be 300 seconds, which is plenty of time for a token to be generated and then presented to the authorisation server. This requirement could be appended to the existing text on client authentication as follows:

The token expiration time SHOULD be no more than 300 seconds later than the time of issue. Authorization servers MAY reject tokens whose lifetime (measured from the "issued at" time if known, or otherwise from the time of receipt) exceeds this.

Alternative solution
None offered

Additional context
None

[garciasolero]

If we are considering adding this restriction for the exp claim, or warning that some implementations may have this restriction, it might be convenient to include a similar statement for the jti claim according to RFC 7523:

The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant.

[eric-murray]

some implementations may have this restriction

ALL implementations will have some limitation on acceptable token lifetime. I am proposing that we make it explicit to the API consumer that tokens with a lifetime less that 300 seconds will be accepted by all authorisation servers. This would be new information for the API consumer.

Your proposed text on jti values is an implementation hint for authorisation servers, but adds no new information for API consumers. CAMARA should try to keep its specifications compact by only providing information that the API consumer needs to know. So I'd prefer not to include such hints.

[AxelNennker]

Please propose some text to https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#client-credentials-flow

[jpengar]

Please propose some text to https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#client-credentials-flow

I think you mean https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#client-authentication, right?

[eric-murray]

Following up from today's meeting:

• For now, I propose this change apply only to the JWT used for client authentication (i.e. the client_assertion), and hence will only propose text for client authentication section referenced by @jpengar. If we make progress on the issues discussing signed authentication requests, then restrictions on the lifetimes of these tokens can be agreed in those issues.
• If the authorisation server rejects a JWT used for client authentication because its expiration date is "unreasonably far in the future", the appropriate error to return appears to be invalid_client, delivered with a 400 for the /token endpoint or a 401 for the /bc-authorize endpoint.
• @MarkCornall mentioned he would like all authorisation servers to apply the 300 second limit, and reject tokens with a longer lifetime. The issue with trying to standardise this behaviour is that the iat (issued at) field of the JWT is not mandatory, and so the authorisation server can only measure the remaining lifetime from when they receive the token. I see two options here:
  • Mandate the iat claim for private_key_jwt tokens (this is already mandatory for CIBA signed authentication requests) and thus limit the allowed token lifetime, irrespective of when the token was presented to the authorisation server; or
  • Limit the allowed remaining lifetime of the token when presented to the authorisation server, irrespective of whether or not the token contains an iat claim

Let me have any further thoughts by end of the week, and I'll propose some text early next week