private_key_jwt assetion tokens can have unbounded expiration which can fill data store

[mitar]

private_key_jwt assetion tokens can have unbounded expiration which can fill data store

[james-d-elliott]

Related: https://datatracker.ietf.org/doc/html/rfc7523#section-3

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

[vivshankar]

In our customized implementation of client authentication, which includes other stuff like tls_client_auth and the ability to choose between custom trust stores and jwks/jwks_uri, we introduced a new configurator interface for exactly the purpose that @james-d-elliott highlighted. We then check for a few things -

1. iat unreasonably far in the past
2. exp unreasonably far in the future
3. (exp-iat) longer than a configured allowed lifetime value to prevent particularly long-lived JWTs and to enforce "freshness"

We happen to do this for all incoming JWTs, not just the client_assertion used for private_key_jwt. There are other practical things to consider adding like a clock skew setting.

[mitar]

It seems I missed this. There is GrantTypeJWTBearerMaxDuration config which seems to control this and it defaults to 1 day.