We currently have setup Auth0 to have two APIs, connected through to two different applications (which correspond to multiple actual web applications).
As we feel our way around Auth0 and find out what’s possible, we’ve decided to have two different token expiries for the two APIs - one being 2 hours, the second being 24 hours. The reasoning behind the different expiries is due to the nature of access - one API is used to access data in a publically accessible web application that is widely available, the other to access data in a publically available but much less available application (and really internal only application).
My question around this is how Auth0 handles SSO and token expiries in this scenario. Are tokens to both APIs/Applications maintained, and when one expires, the user needs to request another from Auth0? Or is whatever token was set most recently used?
A scenario I can think of is a user logging in to the 2 hour expiry API/Application, then moving on to the 24 hour expiry API/Application via SSO. Will the user then be forced to re-authenticate via Auth0 (really just a redirect in this case) if going back to the first API/Application after 2 hours? Or are they now logged in to both for 24 hours?
Welcome to the Community! You need to consider the timeout for:
Access tokens - set in the API configuration,
ID tokens - set in the app configuration,
SSO session timeout - set in tenant configuration
Getting a new access token requires the user to authenticate / approve the access, unless you request a refresh token with your access token, in which case the refresh token never expires and can be used to request a new access token at any time, until it is revoked manually. The typical model here is: short access token expiry (say, 5 minutes), refresh token to get new access tokens as required, revoke the refresh token if you need to revoke the client’s privileges.
Getting a new ID token is (or can be) invisible to the user if the SSO session is still active. Otherwise, they will need to reauthenticate. Again, you can keep your ID token expiry short, and set your SSO session and inactivity timeouts to whatever you feel is appropriate.
In your example, the user will be able to move back and forth between the applications without needing to re-authenticate as long as their SSO session is active. Tokens that expire will be renewed without user interaction if your apps are using refresh tokens and if your SSO session timeout is greater than your token timeouts.
I guess with this flow, it’s worth mentioning that we are not using refresh tokens, as these are SPAs and thus not secure enough to handle and store these. We’re using the silent refresh flow with this SPA, so I assume the SSO is what is allowing the user to continually get more access tokens.
Is the answer here that the SSO timeout is the one that is going to be used across the board? I.e. if a user is logged in to the application using the API that provides only 2 hour long tokens, but the SSO timeout is set to 24 hours, the user will stay logged in for 24 hours?
That’s pretty much it. If you specify a 2 hour token timeout, and a 24 hour SSO timeout, you’ll renew every 2 hours until you hit 24 hours. But there’s also the inactivity timeout, which you can use to kill the SSO session of an idle user. All of this applies only to the idToken, if I remember correctly.
The absence of a refresh token just means the user has to be present to renew the access token.