Checking token validity/expiry

General
,
#1

My goal has always been to implement the architecture proposed in this article. Basically I want access tokens (i.e. opaque) to be exchanged on the internet, and ID token (i.e. JWT) inside my private network. With Auth0 I’ve used the following architecture:

![alt text][1]

My web client uses Auth0.js to login, auth0 sends both access token and JWT. All API calls to my backend server go through an API Gateway (edge service) which expects the access token to be passed in the headers. The edge service will then call /userinfo endpoint from auth0 to get the user profile. It then creates its own JWT using this profile, signed with my own keys as opposed to the Auth0 key.

This has the major drawback of making a call to Auth0 for every API call, so I’ve added caching of the /userinfo response. However this API call does not return the expiry date of the access token. Thus, if I use the access token as the key in my cache, I cannot know when this access token will expire.

Is there a way in Auth0 to know the expiry date of an access token?

Alternatively, is there a better architecture? Do people usually send an ID token to their backend so it can be verified without calls to Auth0?

#2

A typical access token [payload] (https://auth0.com/docs/jwt#payload) will look something like:

{
  "iss": "https://issuer.com/",
  "sub": "auth0|XXXXXXXXXXXXXXXXXXXXXXXX",
  "aud": "https://audience.com/",
  "iat": 1518189923,
  "exp": 1518197123,
  "azp": "XXXXXXXXXXXXXXXXXXXXXXXX",
  "scope": "openid profile email"
}

As you can see, you have two unix timestamps, iat and exp, the Issued At and the Expiration Time claims, respectively. You can check the validity of the access token by decoding it and checking the exp value. For more info on decoding JWTs, please check: https://github.com/auth0/jwt-decode

#3

That very much looks like an ID token (i.e a JWT) and not the access token (i.e. opaque) I was referring to

#4

Access tokens can also be JWTs, this would enable you to check the expiration value. From the documentation:

If the audience is set to the unique
identifier of a custom API, then the
Access Token will be a JSON Web Token
(JWT).

#5

yes I know, that’s the alternative design I am mentioning in my question. I’ve actually already done that, I now send a JWT instead of an opaque token. But I’m still curious to see if people consider this best practice or not

#6

Hi Cesar,

I know you were going with JWT tokens but have you tried to use opaque tokens again? I’m curious because I’m having the exact same scenario and I’m having the same issue (at first I hoped I would find a solution when I read your initial request). So if you managed to use the opaque access token I would like to know how you solved it (or not).

#7

Hi Daniel,

In the end I reverted to using JWT tokens and gave up on using opaque access tokens. It seems that everyone is using JWT and trying to force the use of opaque tokens was causing too much overhead.

So I gave up on that architecture in which only opaque tokens are are exchanged over the internet and JWT are used internally only. This was already invalidated by auth0 who sends the JWT to the web client anyway.

Everything works well with the JWT.

I hope that helps.

1 Like
#8

Thanks for your answer. It spares from investigating how to use opaque access tokens.

#9

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.