Tokens
There are three tokens your application will work with when using Sign in with Vercel:
The ID Token is a signed JWT that contains information about the user who is signing in. When using ID Token claims, your application should both decode the token and verify its signature against the public JWKS endpoint to ensure authenticity. The ID Token does not give access to Vercel resources, it only proves the user's identity.
The code below shows how to decode and validate an ID token using the jose library:
Vercel's IdP generates OpenID Connect tokens that contain various JWT claims depending on the requested scopes:
| Claim | Type | Description | Example |
|---|---|---|---|
| string | Issuer - The server that issued the token | ||
| string | Subject - Unique identifier for the authenticated user | ||
| string | Audience - The ID of the Vercel application | ||
| number | Expiration time - Unix timestamp when the token expires | ||
| number | Issued at - Unix timestamp when the token was issued | ||
| number | Not before - Unix timestamp before which the token is invalid | ||
| string | JWT ID - Unique identifier for this specific token | ||
| string | Cryptographic nonce for replay protection |
Depending on the scopes requested the following claims will be included in the ID Token:
| Scope | Claims | Description | Example |
|---|---|---|---|
| The user's full display name | |||
| The user's username on Vercel | |||
| URL to the user's avatar image (only if user has an avatar) | |||
| The user's email address |
The Access Token grants your application permission to access specific resources on Vercel on behalf of the user trying to sign in. It is used to authenticate requests to Vercel's REST API. Access Tokens use an opaque format that ensures they are not readable by humans, are secure, and have server side validation to ensure they are not tampered with.
Access Tokens are valid for one hour. Refresh Tokens can be exchanged to receive new Access Tokens when they expire. Refresh Tokens are valid for 30 days. When you exchange a Refresh Token for an Access Token, you also receive a new Refresh Token.
When using the Access Token in your application code to fetch the user's data, it must be included in the header as a Bearer token.
Refresh Tokens allow your application to get a new Access Token without asking the user to sign in again. The token lasts for 30 days and rotates each time it's used. When the Access Token expires or is about to expire, a Refresh Token can be exchanged for a new Access and Refresh token pair.
Each Refresh Token is single use and automatically rotated on exchange, invalidating the previous token.
Refresh Tokens use an opaque format that ensures they are not readable by humans, are secure, and have server side validation to ensure they are not tampered with.
Access and Refresh Tokens are sensitive credentials and should be stored securely. Never expose them to the client side of your application.
- They can be stored in cookies with the , and attributes
- They can be stored in a database with encryption
- Revoke tokens immediately if you suspect they have been compromised, either by calling the Revoke Token Endpoint or by invalidating all tokens for your application from the dashboard. See manage Sign in with Vercel from the dashboard for more information.
Was this helpful?