In the browser developer console, a refresh token may appear to have the same expiration timestamp as the Access token and ID token, even when configured with a significantly different lifetime value under the Authorization Server's Access Policies under Security > API > Authorization server > Access Polices > Edit Rule as different values.

• OpenID Connect/OAuth application
• Okta JavaScript SDKs (AuthJS, Widget, React, Angular, Vue)
• Okta Identity Engine (OIE)

When using our JavaScript SDKs, the library stores the user's tokens using the chosen storageManager. When storing these tokens, the storage manager requires that each token in storage have an expiration time set.

Unlike ID and Access tokens, which are in JWT format and include an exp value indicating when the token will expire in the decoded payload, the Refresh token is opaque and cannot be parsed to determine its expiration date/time. To successfully store the token, the SDK sets the Refresh token's expiration time to the value in the Access Token, but this value does not reflect the Refresh token's true expiration.

To verify the actual expiration and validity of a Refresh token, perform a server-side validation. Use the Introspection endpoint of the specific Authorization Server that issued the token.

For the Org Authorization Server

Use the following API call:

curl -i -X POST \
  'https://{youroktadomain}/oauth2/v1/introspect' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d token=string \
  -d token_type_hint=refresh_token

For a Custom Authorization Server

Use the following API call:

curl -i -X POST \
  'https://{youroktadomain}/oauth2/{authorizationServerId}/v1/introspect' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d token=string \
  -d token_type_hint=refresh_token

The server response will contain the correct exp (expiration) timestamp and the active status of the token.

Related References

• okta-auth-js
• Introspect Endpoint
• Authorization Server Types