When modifying the Token Expiration For Browser Flows (Seconds) setting for an API, it states:
Expiration value (in seconds) for access tokens issued for this API via Implicit or Hybrid Flows. Cannot be greater than the Token Lifetime value.
However it is not clear what the Token Lifetime Value is coming from. If I attempt to set this to more than 86400 seconds it shows an error:
Payload validation error: ‘Value 86401 is greater than maximum 86400’ on property token_lifetime_for_web (The amount of time (in seconds) that the token will be valid after being issued from browser based flows. Value cannot be larger than token_lifetime).
Can the maximum be adjusted somewhere else? It does not appear to be related to the field above it Token Expiration (Seconds). Does anyone know if this 86400 is a hard limit or it can be adjusted somewhere?
The Token Expiration For Browser Flows (Seconds) can’t currently exceed the maximum value 86400 or the value configured for Token Expiration (Seconds).
This means that although you can adjust the value for Token Expiration (Seconds) the expiration for browser flows will still be limited by the maximum value of 86400 which is not configurable. In addition, I submitted a request to improve the documentation around this field.
Can you explain why for the access_token issued for a browser flow (e.g. implicit grant) the max expiration value is only 24 hours (86400)? I can see why having it larger could be a security concern in the minds of many, but why not let users configure a value > 86,400 seconds in this scenario if they so choose? Is it purely a security decision by Auth0?
Disclaimer: personal considerations follow, I am not in any way associated with Auth0.
Access tokens cannot be revoked/invalidated in any way. Why would you want to make them last longer? Having a solid, completely configurable refreshing mechanism is the best thing to do here. Consider that having a short/long expiration mechanism is just and optimization, since long lasting tokens/cookies can be invalidated, but are used rarely, while short ones cannot but should in fact not last long.
My main concern here is that Auth0 switched from id tokens + refresh tokens to the new renewAuth (silent authenticaiton), which is good, but the hard limits/lack of flexibility on the new implementation does not allow to fully cover scenarios that were instead covered by the refresh token.
At the moment, you have to reinvent your solution to repeat what Auth0 already did with renewAuth just to have some cookies and session last longer. I hope they’ll do something soon. I gladly play for services, but they must help me out working less.
@joe.tillotson It mostly comes down to what @mbraga said; the browser is a really bad place to store long-lived tokens so it’s a matter of security. The renew token process would allow for a user that uses your application frequently to continue to get tokens automatically for up to thirty days. After the thirty days there’s the maximum limit we currently impose to session cookies and as already mentioned, the user would be forced to input their credentials again. We’re considering increasing the limit, but no timeline for that change.
For the sake of completeness, the major problem here is not having to enter the password once every 30 days, but having to enter it if I don’t log every 3 days. This is far more annoying because for some user usage patterns, it means they’ll have to enter the password every time they use the service.
Thanks all, the above comments make sense, and thus far as I’ve developed my company’s first web SPA client (using Auth0 for OAuth2 / OIDC) I’ve set access_token expiration to 60 mins. If the silent renewal code I’ve developed vis-a-vis auth0.js (from a sample provided by Auth0 author ‘chenkie’) proves to be bullet-proof so to speak, we may configure token lifetime lower (e.g. 30 mins or even less). I think that the issue here as stated above is that the Auth0 Dashboard UI doesn’t explain well why the max is 24 hours, and the wording implies there’s a ‘token lifetime’ which is mysterious.
This should be fully configurable. Auth0 should not impose on how lax or stringent individual applications want to make their tokens. Now I have to re-do my entire authentication flow from the browser to the server-side just to get a long-lasting token. (And no, my users cannot refresh their tokens as they’re not using the token in-browser).
