Support overriding of the default access/refresh token lifespans

[ngrigoriev]

Is your feature request related to a problem? Please describe.

We want different applications to have different lifespans of the access tokens. This is particularly important in the multi-tenant environments where the customer may have requirements different from our defaults.

Describe the solution you'd like

I think it would be great to have it done this way:

• consent provider could have an optional parameter in the accept consent request allowing to override the default access/refresh token lifespans. This gives the maximum flexibility.
• these override values can be (optional) configuration parameters of the clients, e.g. stored in the database along with other client parameters
• if nothing is provided, then the global default value is used
• (optional) as a safeguard, it would be great to have min/max allowed values for access/refresh token lifespans. If not provided, they could be initialized to the same values as default lifespan. This way a reasonable range could be enforced.

Describe alternatives you've considered

Multiple Hydra deployments - but this creates significant complexity and does not scale beyond 2-3 different tenants.

Additional context

N/A

[aeneasr]

While I wouldn't rule this out in general - the problem with setting this on a per-client basis is that some clients will use oauth2 access tokens as long living tokens or as a substitute for API keys - which is not a suitable use case for these types of tokens.

Why is the duration of the access token relevant if it can be refreshed any time?

[ngrigoriev]

I'd say it for us it is mostly about the customer requirements. We may think that 6 hours is a reasonable default but the customer may insist on 2 or 3 hours. This also gets a bit more sensetive when JWT token is used - since those cannot be truly revoked until they expire (from Oathkeeper's "jwt" authorizer standpoint, for example). So, I know that we may need to play the lifespan to meet some requirements.

On another side, we want to avoid having to refresh the tokens too often because we have some latency-sensetive apps and we hope to avoid the "cold start" latency during the anticipated user session period. But even this period may be different for different apps.

Bottom line: it is not about going to something low or something above a day - it is about having some freedom between, say, 2 hours and 8 hours for different apps.

The same applies to the refresh token.

And the reason why, I think, it may be cool to have that configurable at consent/login provider level is more or less the same: we have a cloud-based SaaS with multiple tenants. We do go through security review process with different customers and they, while understanding how OAuth2 works, may set the requirement for different access token lifespan for their users. Which means I may have one OAuth2 client that requires slightly different token lifespans for the users from different tenants.

[aeneasr]

Ok so what do you think about simply limiting access token lifetime to e.g. 7 days (which is way above what's recommended anyways) and then allowing for a per-client config (or alternatively allowing the consent app to define lifespan)?

[ngrigoriev]

I think this would do - basically, setting the max to the value determined by the environment and then being able to "lower" it via client config and consent app (nice to have). And I think it would be the ultimate flexibility if the same logic applies to both access and refresh tokens (independently, of course).

[glerchundi]

Ok so what do you think about simply limiting access token lifetime to e.g. 7 days (which is way above what's recommended anyways) and then allowing for a per-client config (or alternatively allowing the consent app to define lifespan)?

We didn't decided yet but some members of my team put on the table the possibility of changing lifetimes on a per client basis due to the different requirements each client have. I.e Web and iOS/Android apps.

Just putting my 2cents in.

[aeneasr]

Thank you :) As I've said before - if you have a refresh token the lifetime of an access token is negligible (in most cases) and best to keep reasonably short! In the scenario of web/native apps this definitely applies and you will have more complexity if you have different lifetimes as you will have when just following the refresh token flow.

[timkelley-ingage]

@aeneasr : I noticed that is issue is suggesting exactly what I had discussed around adding custom token expiration times (access_token_expiration, refresh_token_expiration) to the client data.

Here is the excerpt from pertaining to this from the separate issue:

This is not the case for ALL scenarios.. We have scenarios where we want to utilize the same Identity Provider (token minting) for different aspects of our business that require stricter security controls. With the ability to utilize the meta data we could generate tokens with different expiry times based on risk considerations of the data that they can retrieve as well as their "footprint" to our business. It doesn't make sense to stand up many Identity Providers with slightly different configurations as it just grows our security vectors without adding much benefit when it can be achieved in a single solution.

This piece is the only part of this discussion I don't necessarily agree with:

I think this would do - basically, setting the max to the value determined by the environment and then being able to "lower" it via client config and consent app (nice to have)
I am not sure why the max would be determined by the environment. Why not just have a default for each expiration that is set by the environment, then override with values for the client?

[aeneasr]

I've tagged & labeled this issue so we can keep better track of it. I'm still not 100% convinced that this is neccesary / a good idea but it has been requested quite a lot. Maybe it would be easier to understand if you could share why exactly you need higher or lower times and what concrete outcome you expect of it?

[ngrigoriev]

Here is one use case that I can think of - real one for us. We have different API clients including some apps that are used by the call center agents. Their work day is usually around 8 hours or so. They start in the morning and they actively interact with the app (web app specifically) during the entire day. It is critical that the apps they use are working without any interruptions for the day.

Yes, I agree that the refresh, even in case of the simplest implicit grant, should be silent and non-intrusive. But in my case I am relying on the external IdP so when the refresh happens that IdP may break the "silent" refresh process and force the interactive logic - the agent will not be able to handle the call if suddenly he/she needs to put the password, probably 2FA...

Another case for us - API is one of our products. We have important enterprise customers who may have similar requirements. If we say that the token lifespan is 1 hour and the customer insists that they want to have it 4 hours - we do not necessarily want to argue too much. Yes, if they say 40 hours for the access tokens, we would really need to deal with it. But while within reasonable timeframe, we want to rather satisfy the customer's requerements but only in the scope of this customer, not having to change these lifespan values for everyone else, including ourselves.