Set token exp, jti in Client Credentials Exchange Hook

Help
, , , ,
1

I’d like to be able to adjust the token’s exp in my client_credentials exchange hook. It’s currently determined by the token expiration time in the settings of the API named in the audience of the token request. That’s great, but doesn’t cover two use cases:

  • Lowering the timeout for test clients
  • Raising the timeout beyond the default 30 day limit for customers who demand such

To make longer-lived tokens revocable, we’d want to set a jti along with the exp.

2

We appreciate the feedback in relation to the possibility of dynamically adjusting the token expiration. I would recommend you to vote on an already existing idea that includes that exact scenario. Although I can’t provide a definitive answer if/when will this be supported the more evidences exist that this is a desired feature the likelier it will that the situation gets addressed.

Allow to Modify Access Token Expiration From Rules and Hooks in OIDC Flows

In relation to the jti situation this may be a general limitation imposed on dynamic claims that can be added to JWT tokens in general. An existing workaround would be for you to include that information as part of a namespaced custom claim for which support already exists. More specifically, including the following in your hook should allow you to obtain a somewhat equivalent implementation:

access_token'https://example.com/jti'] = '[unique_id_here]';
3

You could, similarly, argue we could implement custom scopes with a namespaced custom claim. I’m not sure it holds up. Also, your blacklist API requires jti.

If you’re going to offer modification of any RFC 7519 registered claims, please do all those at once that make sense: exp, nbf and jti. I think there’s less of a case for iss, sub, aud, and iat; see @gavin.osborn’s 2196 for more. Cheers!

4

If it came across that I was trying to argue in favor of the use of custom namespaced claim for the jti scenario then it was my bad for not making it clearer. I was just trying to provide you with an alternative given the current limitation. Also have in mind that, to my knowledge, the blacklist API you mention is intended for Management API 2 tokens and I assumed you wanted to blacklist tokens issued to your own API’s which would mean the blacklist implementation would be yours and as such the custom claim could be handled.