Seemingly able to renew access_token with expired id_token

Hi, I’m trying to test what happens when my tokens expire in my app, so I’m purposely setting the timeouts low, but no matter what I try, I’m always able to renew my access_token ???

Here are my settings:

Client:
JWT Expiration (seconds): 30

API:
Token Expiration (Seconds): 20

Token Expiration For Browser Flows (Seconds): 10

After logging in… I can close the browser and wait several minutes. When I reopen the app, it’s able to successfully renew the access_token using the (supposedly) expired id_token. Am I missing something? Thanks for your help!

Can you elaborate a bit more on how you are renewing your tokens? I see two ways that token reissuance or renewal can happen:

  1. with a refresh token. In this flow neither the access_token or id_token are used to refresh the token. Instead a refresh token is used and this token does not expire.

  2. More likely you are using auth0.js or some other SDK to renew tokens. With this method a call is made to the /authorize endpoint with a get parameter prompt=none. This flow also doesn’t use an access_token or id_token for renewal. Instead Auth0 redirects the user to Auth0 and a session cookie is used to determine if the user can login without being prompted for credentials, mfa, etc. Assuming all the rules pass the application will be given new tokens.

In general the id_token and access_token should be as short lived as possible. When they expire they can be renewed.

1 Like

Thanks for your response. I am using auth0.js following the latest tutorial in Hosted Page authentication with silent refresh.

So, I assume it’s then the SSO Timeout in the tenant settings that determines how long you can refresh a token for? It looks like the longest you can set that for is 30 days.

Just so I understand correctly, assuming I set the SSO Timeout for 30 days, does that mean that if a user is using my app daily, their session will all of a sudden “go bad” 30 days after they logged in and they’ll have to log in again? I’d like to avoid this scenario if possible. I’d like a user who is constantly active to never have to log in again unless they explicitly log out.

So, I assume it’s then the SSO Timeout in the tenant settings that determines how long you can refresh a token for? It looks like the longest you can set that for is 30 days.

Yes, this is correct. Auth0.js is opening an iframe and taking the user through the /authorize?prompt=none... flow. During this flow the browser will send the auth0 session cookie. The timeout you are configuring is a fixed timeout. Meaning, like you said after 30 days (or whatever is configured) the cookie will expire. There is also a sliding expiration, which is not currently confgurable (we intend to eventually allow this to be configurable) that expires 3 days after inactivity.

I’d like a user who is constantly active to never have to log in again unless they explicitly log out.

In a single page application this is not possible today, because those cookies will eventually expires (3 days of inactivity or a maximum of whatever is configured). To achieve what you want would require a refresh token. This effectively gives you the ability to refresh tokens forever since refresh tokens do not expire. If you are using an appropriate client type you could use refresh tokens.

2 Likes

Thanks for your fast response, looks like refresh tokens are what I want then. Time to look at some tutorials!

1 Like

hmm… so according to your documentation, refresh tokens are not secure for SPA applications.

Is there any way to silently renew the session cookie so that an active user doesn’t get disrupted when their session cookie expires?

I must be missing something. There has to be a way for an active user of a SPA to stay logged in indefinitely without having to enter a login screen. If not, would your team consider allowing extending the length of the session cookie beyond 30 days? Perhaps up to 1 year?

hmm… so according to your documentation, refresh tokens are not secure for SPA applications.

Yes, this is correct. I mentioned this above, but did not punctuate the point my apologies for that.

Is there any way to silently renew the session cookie so that an active user doesn’t get disrupted when their session cookie expires?

The session cookie is the only way we do Single Sign On after their JWTs expire. As I mentioned today the only mechanism for allowing indefinite sessions is a refresh token and that should not be used in a SPA.

If not, would your team consider allowing extending the length of the session cookie beyond 30 days? Perhaps up to 1 year?

We are happy to take feature requests. I think product would be happy to hear any ideas. I do know they are looking at providing more configuration options. However, we don’t have any details at this time. If you could post your feature request on community I will also pass it along internally.