Hi Team,
I’ve asked about that before (1)]1, and there was a similar question recently (2)]2, but just to re-iterate: is it possible to set token expiration time for each connection for the tokens that target an API?
Currently, I can set token lifetime per-API separately for non-interactive clients (via token_lifetime) and web flow clients (via token_lifetime_for_web, which btw is not documented in (3)]3).
However, I would like to have further configurability for my web clients on a per-connection basis. Namely, for my passwordless email connections I’d like to set a shorter lifetime (e.g. 1h), and for google-oauth2 or other social connections - a longer one (e.g. 24h).
I was hoping to achieve that through a rule, by modifying context.jwtConfiguration.lifetimeInSeconds, but as mentioned in (1)]1 and (2)]2 that is not possible at the moment.
Would there be any other way to enforce that on Auth0 server-side?
My ultimate goal is to allow clients to use social connections on their personal computers for longer sessions in my SPA, but to only allow short sessions if they log in from a ‘public’ computer using a temporary code (which they would not otherwise entrust with their Google etc. credentials).
One workaround may be to create a timeout in my client code that, depending on the connection used to obtain the token, will simply remove the token from localStorage after a period of inactivity, and trigger re-authentication. That seems to be achievable with some workarounds, but I’d still like to know if there is a better way.
Thanks a lot!
That is currently unavailable.
Besides the workaround you mentioned I would consider enforcing that logic on the API itself based on the iat claim and an additional custom claim that you could include in the access token based on the connection/method of authentication. Enforcing this at the API has the benefit that end-user can’t mess with it as it would be the case if the logic was only done in a client-side application.
Also note that the setting you mentioned context.jwtConfiguration.lifetimeInSeconds which is currently not being applied consistently throughout all the possible endpoints, as far as I’m aware, is meant to influence only the ID token issued as part of user authentication. I suspect that at the time that setting was introduced, API authorization was not yet available so the only token that could be a JWT was the ID token one, hence the name. However, this is my understanding of it. As per your second reference, the outcome for jwtConfiguration.lifetimeInSeconds is still on the table and I can’t provide any further information about if it will be supported across all endpoints and/or if it will affect ID tokens only.
In relation to the missing documentation on the resource server API endpoint I made an internal request to get that updated.
Thanks, I agree that the server-side approach is more robust in general.
However, in our case we don’t intend this to be a security mechanism; it’s just to prevent accidental reuse of accounts by users logging in later on the same computer, where all users are trusted. We want to check for user inactivity and log them out (potentially earlier than the token expiration time); this can be done client side. In untrusted environments it would be inappropriate.
Still, server-side enforcement would be uncompromised and maybe easier to implement. I’ll likely go with a custom claim + iat.
Thanks, I agree that the server-side approach is more robust in general.
However, in our case we don’t intend this to be a security mechanism; it’s just to prevent accidental reuse of accounts by users logging in later on the same computer, where all users are trusted. We want to check for user inactivity and log them out (potentially earlier than the token expiration time); this can be done client side. In untrusted environments it would be inappropriate.
Still, server-side enforcement would be uncompromised and maybe easier to implement. I’ll likely go with a custom claim + iat.