Anonymous Sessions

Anonymous sessions allow you to create and manage user sessions without requiring authentication. Users can browse, add items to carts or wishlists, complete purchases, and set preferences before creating an account. Users then bring their activity into their authenticated profile when they sign up or log in. Use anonymous sessions for the following use cases:

Track guest users across page loads and sessions
Store metadata such as shopping cart references, preferences, consents, and profiling information
Issue access tokens for API calls without requiring authentication
Transfer anonymous activity to authenticated accounts when users sign up or log in

Auth0 anonymous session Metadata is not a secure data store and should not be used to store sensitive information. This includes secrets and high-risk PII like social security numbers or credit card numbers, etc.Additionally, the data stored in an anonymous session is not verified for truthness or accuracy and should never be taken at face value.Auth0 customers are strongly encouraged to evaluate the data stored in metadata and only store that which is necessary for session tagging and access management purposes. To learn more, read Auth0 General Data Protection Regulation Compliance.”

How it works

Gather anonymous sessions data

When you decide to start gathering information about a user, even one who has not authenticated yet, your application sends a POST request to the /anonymous/token endpoint. Auth0 responds with two tokens:

A session token that identifies and persists the anonymous session.
An access token that the user can present to your resource servers (APIs).

Subsequent calls that include the session token continue the same session for the same user_id, so all activity is traceable to a single origin. Using the access token, anonymous users can call any of your existing APIs.

Anonymous session data of user anon@1234-5678-90

{
  "user_id": "anon@1234-5678-90",
  "session_id": "sess_456",
  "metadata": {
    "language": "EN",
    "country": "US",
    "purchase": "P0123"
  }
}

Transfer anonymous sessions data to user’s metadata

There are different mechanisms to transfer an anonymous session into an authenticated user, depending on the flow you are using and where your application resides in terms of domains and FQDNs.

Transferring a session in redirect flows (authorization code, authorization code with PKCE)

Transferring a session through a cookie

When a user who has an anonymous session decides to log in or sign up, your application passes the anonymous_session_token to the /authorize endpoint using a cookie. This mechanism works when your application and the authorization server live in the same domain — for example, when your application lives in application.mydomain.com and the authorization server’s custom domain is auth.mydomain.com. In this case, the cookie is considered same-domain and forwarded to the authorization server automatically, so logging in works as usual:

cookie example

// No extra code needed — cookie is sent automatically
await auth0.loginWithRedirect();

Transferring a session through a transfer ticket

In scenarios where cookies would need to travel cross-domain, multiple browser mechanisms will block the anonymous session cookie from being sent over the network. Even with the correct CORS configuration on the server and client, advanced mechanisms such as Apple’s Intelligent Tracking Protection (ITP) may block or drop the cookie, resulting in unmatched users. To overcome this, use a two-step anonymous session transfer mechanism that does not rely on cookies:

Call the /anonymous/token endpoint, requesting the urn:auth0:anon_transfer_token audience, to receive an anon_transfer_token in exchange.
Include the anon_transfer_token as a parameter in the /authorize call.

The anon_transfer_token is bound to the IP address that requested it. If you plan to use this cookieless mechanism for login, Auth0 recommends turning off the issuance of anonymous session cookies in your tenant settings to avoid undesired clashes or injections. Upon successful login, Auth0 makes the anonymous session data available in your pre-user-registration and post-login Actions triggers using the event.anonymous_session object.

anonymous session object

{
  "anonymous_session": {
    "user_id": "anon@1234-5678-90",
    "session_id": "sess_123",
    "created_at": "2026-05-14T10:30:00Z",
    "metadata": {
      "language": "en",
      "country": "US",
      "order_id": "PO123"
    }
  }
}

Transferring a session in a Resource Owner Password Grant (ROPG) scenario

When using ROPG for login, include the anonymous_session_token in the request body of the /oauth/token call:

Anonymous session token in a ROPG request

POST /oauth/token HTTP/1.1

username=<username>&
password=<password>&
client_id=<client_id>&
scope=<desired scopes>&
grant_type=http://auth0.com/oauth/grant-type/password-realm&
client_secret=<secret>&
realm=<database or realm>&
audience=<desired audience>&
anonymous_session_token=ANONYMOUS_SESSION_eyJ...

To learn more about anonymous sessions with Actions, read Anonymous Sessions Use Cases.

End the anonymous session after transfer

Anonymous session cookies are not automatically flushed when a user authenticates, so the cookie can continue to be sent in subsequent logins. To end the session, use the /anonymous/logout endpoint:

// In your application, after successful login
if (wasAnonymousSession) {
  await fetch('https://YOUR_DOMAIN/anonymous/logout', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    credentials: 'include', // Send cookies
    body: JSON.stringify({ client_id: 'YOUR_CLIENT_ID' }),
  });
}

Auth0 does not offer server-side invalidation for anonymous sessions. Logging out a session only cleans up the anonymous session cookie — if the browser or application retains the token after the cookie is cleaned up, that token can still be used normally. If you want more control over anonymous sessions, you can configure your tenant to not issue cookies for anonymous sessions at all — see Configure anonymous sessions in your Auth0 tenant.

Best practices

Here are some best practices for anonymous sessions:

Configure appropriate anonymous session lifetimes to avoid losing a user’s anonymous session data; Auth0 recommends a lifetime of 30 days or longer.
Select anonymous session’s JSON Web Encryption (JWE) encryption to ensure that potential attackers cannot see the contents of the session.
Restrict what anonymous anon@ users can do in your API.
Validate tokens and sanitize metadata, never trust metadata or tokens from clients without server-side validation.
Cache access tokens since they can be reused until they expire.
Batch and minimize metadata updates. Avoid frequent metadata updates.

Limitations

Password reset flows are not supported by anonymous sessions.
Device Code is not supported because the authentication request and the actual login happen on different devices.
Client-Initiated Backchannel Authentication (CIBA) is not supported because the authentication request and confirmation happen on different devices.
Custom token exchange is not supported due to the nature of the transactions (for example, impersonation), which creates a likelihood of attributing anonymous data to the wrong user.
Refresh token exchange is not supported by anonymous sessions because the user is already logged in if they had a refresh token.

Learn more

Configure Anonymous Sessions Learn how to configure anonymous sessions.
Configure Custom Claims for Anonymous Sessions Learn how to map anonymous session metadata into access token claims.
Anonymous Sessions Use Cases Learn about anonymous sessions use cases.

Manage Users

Manage Access

How it works

Gather anonymous sessions data

Transfer anonymous sessions data to user’s metadata

Transferring a session in redirect flows (authorization code, authorization code with PKCE)

Transferring a session through a cookie

Transferring a session through a transfer ticket

Transferring a session in a Resource Owner Password Grant (ROPG) scenario

End the anonymous session after transfer

Best practices

Limitations

Learn more

​How it works

​Gather anonymous sessions data

​Transfer anonymous sessions data to user’s metadata

​Transferring a session in redirect flows (authorization code, authorization code with PKCE)

Transferring a session through a cookie

Transferring a session through a transfer ticket

​Transferring a session in a Resource Owner Password Grant (ROPG) scenario

​End the anonymous session after transfer

​Best practices

​Limitations

​Learn more

How it works

Gather anonymous sessions data

Transfer anonymous sessions data to user’s metadata

Transferring a session in redirect flows (authorization code, authorization code with PKCE)

Transferring a session in a Resource Owner Password Grant (ROPG) scenario

End the anonymous session after transfer

Best practices

Limitations

Learn more