Skip to main content

Overview

The TokenSet interface represents the collection of tokens returned by Auth0 after successful authentication or token refresh. It includes access tokens, ID tokens, refresh tokens, and associated metadata.

Type Definition

Properties

string
required
The access token issued by Auth0. This token is used to authenticate requests to your API or resource server.
string
The ID token containing user profile information as JWT claims. This token follows the OpenID Connect specification and contains information about the authenticated user.
string
The actual scope granted by the authorization server. This may differ from the requested scope if the server grants fewer permissions than requested.
string
The scope that was originally requested during authentication.
string
The refresh token that can be used to obtain new access tokens without requiring the user to re-authenticate. This is only present when the offline_access scope is requested.
number
required
Unix timestamp (in seconds since epoch) indicating when the access token expires. Use this to determine if the token needs to be refreshed.
string
The intended audience for the access token. This identifies the API or resource server that the token is intended for.
string
The type of the access token. Common values:
  • "Bearer" - Standard OAuth 2.0 bearer token (default)
  • "DPoP" - Demonstrating Proof-of-Possession token (when DPoP is enabled)

Usage Examples

Get Access Token in Server Components

Get Token with Specific Audience

Force Token Refresh

Check Token Expiration

Multi-Resource Refresh Tokens (MRRT)

When using multiple APIs with different audiences:

Use with API Routes (Pages Router)

Token Refresh Behavior

The SDK automatically handles token refresh when:
  1. Access token is expired - If the current time is past expiresAt
  2. Refresh is forced - When refresh: true is passed to getAccessToken()
  3. Token refresh buffer - When configured, tokens are refreshed before expiration

DPoP Tokens

When DPoP (Demonstrating Proof-of-Possession) is enabled, tokens are cryptographically bound to the client:

Client-Side Token Access

For browser-based apps that need tokens (not recommended for most apps):
Security Best Practice: Avoid exposing access tokens to the browser when possible. Use a Token Mediating Backend pattern where your Next.js API routes call external APIs on behalf of the client.

See Also