Expires_in value is always 86400 SOLVED

[info.manticore-labs]

Hello Everyone,

I created this Topic to ensure that no one else fall in the error that the API returns always 86400 as the time that supposedly the token is going to expire.

Auth0 return you a JWT when you use the: ‘Username-Password-Authentication’, with grant_type “password”.

After you successfully configure everything and send the HTTP request a response like this is send to you:

---

{
“access_token”: “ABCD”,
“refresh_token”: “JDKF”,
“id_token”: “HERE.ISYOUR.TOKEN”,
“scope”: “openid profile email offline_access”,
“expires_in”: 86400,
“token_type”: “Bearer”
}

---

You will ALWAYS receive a supposed “expires_in” with value “86400” inside your response, but this is not trustworthy at ALL.

What you have to do to fix this error?

If you open your JWT with a visual debugger like this: " h t t p s : / / j w t . i o /" (just copy and paste the “id_token” there ), you will notice that your token have a body part (as the standard regulates it), something like this:

Like every JWT, there are 2 important fields so that you can now when is going to expire your token and when was issued. Those fields are: “iat” and “exp”

---

{
“nickname”: “nick.name”,
“name”: “name”,
“picture”: “picture”,
“updated_at”: “2020-01-25T11:45:49.902Z”,
“email”: “vadrian.eguez@gmail.com”,
“email_verified”: true,
“iss”: “link”,
“sub”: “auth0|5e175b205081450e8da5ef33”,
“aud”: “971tc3Ij27pb4O0R6rkykhTOFsMoreLU”,
“iat”: 1579952749,
“exp”: 1579988749
}

---

Those fields are like the getTime() method that returns the number of milliseconds since January 1, 1970, when you compare the time between both dates, this time matches the field JWT Expiration in seconds that is configurable in your account:

SO,

To fix this error, you have to parse your JWT and use those dates to ensure when you really have to refresh the JWT.

That was the fix.

I hope this information is useful for everyone.

Greetings my friends,

Info Manticore-Labs Team.

info@manticore-labs.com

[nicolas_sabena]

Hi @info.manticore-labs, welcome!

Thanks for the detailed write-up. I want to clarify that the expires_in is trustworthy does not really need a fix, the thing is that it is the expiration time for the Access token received in the response, not the ID Token.

When an application asks for a token response with scope=openid it gets two tokens:

• an Access Token, good for making requests to a protected resource (like the /userinfo endpoint in the case of OIDC)
• an ID Token, which is the proof of the user identity and authentication event (to authenticate the user in the app).

Since the format of the Access Token is not specified in the OAuth2 protocol, nor the application (the “client”) that asks for it is supposed to parse it or understand it in any way, the authorization server provides an expires_in value in the response so that the client knows for how long the Access Token is good for.

Auth0 uses opaque tokens when the scope is openid and there’s no audience specified, and JWT format for tokens meant to be used on an external API (like a custom one). In these cases, Auth0 will use the exp claim to inform the expiration time. But, in any case, the application that asks for the token has no business inspecting it (this will be the job of the target audience of the token, the backend API).

The ID Token, on the other hand, is always of JWT format (this is mandated by the OIDC spec) and client applications are the target audiences, so they are supposed to peek into it, validate it and get the claims from it. So, in the case of ID tokens, the expiration time is included directly as part of the token payload as the exp claim.

[info.manticore-labs]

Excellent reply,

Everything is clarified.

Thanks!