Auth0 Home Blog Docs

AccessToken expiration

sdk
v8
access-token
expiration

#1

I am developing silentAuthentication in my SPA and can’t find a simple way to expire accessTokens. The login is done via passwordless verification and I always receive the same value for token expiration (7200) in the url hash, example: #access_token=6JyxGFYyWKG6tQHD&expires_in=7200&token_type=Bearer.

I go to Clients > My app Client > Settings > JWT Expiration (seconds) and change it to 10, but the url keeps send the expires_in=7200. Am I setting in the wrong place?


#2

( +1 ) on this. I’m also working on a SPA using auth0 js v8.8.0 , and no matter what expiration time I set for the client in the auth0 management console, auth0 always responds with expires_in=7200.

My webAuth configuration:

new auth0.WebAuth( {

domain: ‘myDomain’ ,

clientID: ‘myClientId’ ,

redirectUri: ‘http://myDomain/auth/callback’ ,

audience: ‘https://myAccount.auth0.com/userinfo’ ,

responseType: ‘token id_token’ ,

scope: ‘openid profile user_metadata app_metadata offline_access’ ,

leeway: 40

}

Side note: This comment input box is horrible.


#3

The client application setting JWT Expiration impacts the ID token issued as part of an applicable authentication request (not the access token). The ID token is the only token guaranteed to always be a JWT, because the OpenID Connect specification that defines it imposes this format and it’s also the only token meant to be processed directly by the client application.

Other tokens that may be issued, like it’s the case of access tokens and refresh tokens don’t have the same constraints and as such don’t need to be JWT’s. These tokens are issued to client applications, but are not processed by them; the client application should treat these tokens as opaque values. Due to this, the response also includes the expires_in parameter to denote the expiration time of the access token in a way that the client application can process.

When you perform an authentication/authorization request that either does not specify an audience or specifies the /userinfo audience then the expiration time is currently not configurable and it’s the one you observed.

If on the other hand, you specify an audience parameter that maps to your own API that you configured in Auth0 then the expiration of the access token that is meant to be sent to that API can be configured through the following settings available within the API settings:

  • Token Expiration (Seconds)
  • Token Expiration For Browser Flows (Seconds)

#4

@jmangelo From your explanation, I understand that in the case of SPAs (my case and also @kurtmilam 's), the only way to set an access token expiration, even for debugging purposes, is to invent a “fake” api and use it as audience, is it right? and if I need /userinfo in audience, can I have both?


#5

Yes, at this time, that would indeed accomplish your requirement for a custom expiration. If you also need /userinfo then set your API to use RS256 and include openid in the scope as that should allow you to get an access token with two valid audiences (your API and the user information endpoint).


#6

For some reason ... I can't show or hide comments :-( Can't see @jmangelo comment

Uncaught ReferenceError: createWmd is not


#7

For some reason ... I can't show or hide comments :-( Can't see @jmangelo comment

Uncaught ReferenceError: createWmd is not


#8

Apologies for that situation, it should now be resolved.


#9

related to this question (AccessToken expiration for Action-on-Google)[https://community.auth0.com/questions/12212/accesstoken-expiration-for-action-on-google]


#10

related to this question (AccessToken expiration for Action-on-Google)[https://community.auth0.com/questions/12212/accesstoken-expiration-for-action-on-google]


#11

Provided an answer there with some option on how a audience can be included assuming that is indeed the underlying issue.


#12