Auth0 Session & Token Management
Auth0 integration patterns showing how sessions, tokens, and device management work across different client types and security requirements.
Follow the demo script →Core Client Patterns
The foundational shapes — what changes across client type and session storage.
Traditional Web App
Authorization Code Flow with server-side session cookie. Back-Channel Logout propagates revocation to all apps when a session ends. Shows active sessions via the Auth0 Session Management API.
Cookie sessionBack-Channel LogoutSession Management APISession revoke
Open demo →SPA with DPoP
Public browser client, no server-side session at all. DPoP binds the access token to an ephemeral ES256 key pair generated in IndexedDB — a stolen token is useless without the private key. A Post-Login Action stamps Refresh Token Metadata (device, browser, IP) on the refresh token at issuance.
DPoP token bindingRefresh Token MetadataNo server-side session@auth0/auth0-spa-js
Open demo →SPA with Online Refresh Tokens
Online Refresh Tokens are validated server-side on every exchange — Auth0 checks the token store rather than just verifying the signature. Revoke a session and the next getTokenSilently() call fails immediately, with no access-token grace period. No DPoP (intentional — isolates ORT from sender constraining).
Immediate revocationServer-side RT validationRevocation speed testNo AT grace period
Open demo →Backend-for-Frontend
Confidential OAuth client — tokens are stored server-side behind an HttpOnly session cookie and never reach the browser. The browser holds a session cookie; it never sees a bearer token. Multi-Resource Refresh Token (MRRT) exchanges one refresh token for access tokens scoped to multiple API audiences, entirely server-side.
HttpOnly session cookieZero browser token exposureMulti-Resource Refresh TokensPKCE ≠ token storage
Open demo →High Trust App
SSO isolation via sso:false on the Auth0 client. Logging into any other app on this tenant does not carry over — the Authorization Server always forces fresh credentials. Demonstrates per-application session isolation for high-sensitivity surfaces.
sso:falseNo SSO reuseIsolated AS sessionPer-app auth enforcement
Open demo →Session Transfer & SSO
Bridging a session across devices or origins without re-authenticating.
Native-to-Web SSO
Session transfer token bridges a native app session into a web browser session — no password re-entry. Single-use, 60-second expiry, IP-bound. Shows the exact exchange request, raw STT with countdown timer, and both sessions' tokens compared claim-by-claim.
session_transfer_token60s single-useIP-boundClaim diff
Open demo →Cross-Domain SSO
Two genuinely separate web origins, same Auth0 tenant, default SSO settings — the mirror image of the High Trust App demo. Log into Brand A, then hit Brand B's prompt=none check: Auth0's own AS session cookie silently authenticates the second app with no login screen.
prompt=noneShared AS sessionTwo real originslogin_required handling
Open demo →Session Delegation
Auth0's new paved path for impersonation-style access: a support agent (actor) mints a Session Transfer Token via Custom Token Exchange, naming a different (subject) user and their own ID token as actor_token. Redeeming it establishes an ephemeral, 2-hour, IP-bound session as that user with an act claim recording the delegating agent — no refresh token, ever. Live tenant log panel shows the real sdel/sdeleacft/sdelsa audit codes.
Custom Token Exchange + actor_tokenact claim (sub_profile, role)Dedicated sdel* log codesNo refresh tokens, ever
Open demo →Ephemeral Sessions
Auth0's "Manage Sessions with Actions" post-login APIs, applied unconditionally by a dedicated always-ephemeral client rather than a client-asserted "shared device" flag. A Post-Login Action calls api.session.setCookieMode('non-persistent') plus tightened setExpiresAt/setIdleExpiresAt on every login; no offline_access scope means no refresh token is ever minted; this app's own session cookie is independently shortened to match. Session Management API panel shows the real cookie.mode and expiry as ground truth. Compare with Traditional Web App for the persistent-session contrast.
api.session.setCookieMode()setExpiresAt / setIdleExpiresAtNo offline_access — no refresh tokenTwo sessions, both shortened
Open demo →Token Exchange
RFC 8693 — trading one token for another, preserving or mapping identity.
On-Behalf-Of Token Exchange
RFC 8693 token exchange: a middle-tier service presents the user's access token and receives a new token for a downstream API. The user's sub is preserved end-to-end; the act claim records the delegation chain. Demonstrates the canonical pattern for AI agent and microservice architectures.
RFC 8693act delegation chainIdentity preservationAI agent pattern
Open demo →Custom Token Exchange
Exchange any external token — JWT, SAML, or arbitrary format — for full Auth0 AT + ID Token + RT. An Auth0 Action validates the incoming token and maps it to an Auth0 user identity with no browser redirect and no Universal Login. Covers external IdP federation, migration, and device attestation.
Any token formatAuth0 Action validatesNo browser redirectExternal IdP federation
Open demo →Token Vault — Connected Apps
Auth0 Connected Accounts + getAccessTokenForConnection() link Google Calendar and GitHub as secondary connections, independent of the primary login. Two columns compare live results side by side — real-first-fallback means a tester with only one of the two accounts still sees a full comparison, the other column clearly labeled simulated.
Connected AccountsgetAccessTokenForConnection()Real-first-fallbackNo third-party password stored
Open demo →Token Vault — Organization Isolation
Same Connected Accounts mechanism as Token Vault, with an Auth0 Organization added to the login. Connecting Google or GitHub while authenticated into one org is invisible from another — no admin-provisioned, org-wide connection, just per-user consent partitioned by org_id. Switch orgs to see the same identity with two independent token sets.
Auth0 OrganizationsPer-org_id isolationorganization on login, not on the token callNot admin bulk-provisioning
Open demo →Cross App Access (XAA)
Auth0's Early Access Identity Assertion Authorization Grant for AI-agent-to-app access. An enterprise IdP issues a short-lived ID-JAG gated by admin policy; Agent0 (Requesting App) redeems it for a Todo0 (Resource App) access token via a real Auth0 jwt-bearer grant — no consent screen, no shared credential. The Enterprise IdP is simulated locally with jose-generated RS256 keys; Todo0 (Resource App) is real Auth0. Requesting App redemption is Auth0-side not-yet-shipped, so that one call attempts real Auth0 first and falls back to a clearly-labeled mock, switching over automatically once Auth0 ships it.
ID-JAGjwt-bearer grantCentralized policy revocationMCP / AI agent pattern
Open demo →Decoupled & Non-Browser Auth
Authentication that happens away from the requesting device entirely.
CIBA
Client-Initiated Backchannel Authentication — a requesting device sends a real Auth0 Guardian push notification to a separate device for approval, with no redirect and no browser round-trip on the approver's side at all. Requires an Enterprise plan and genuine Guardian enrollment, not a simulated inbox.
Decoupled authReal Guardian pushNo persisted consentEnterprise-only
Open demo →Device Authorization Grant
RFC 8628 Device Code flow for input-constrained clients — a CLI tool or smart TV displays a code, and the user redeems it via real Universal Login on a second screen. No prior session, no MFA dependency, works on any Auth0 plan. Requires a native/public client — no client secret anywhere in the flow.
RFC 8628Second-screen loginPublic client, no secretAny plan
Open demo →Identity Bridging
Connecting pre-authentication activity to a known, authenticated identity.
Anonymous to Known
Capture a PostHog anonymous distinct_id before Auth0 login, then call posthog.identify() after callback to merge the pre-auth browsing journey into the authenticated user profile. In-app reporting panel queries the PostHog Events API to show the stitched timeline.
PostHog identify()Anonymous distinct_idPerson mergeEvents API reporting
Open demo →Auth0 Anonymous Sessions
A first-party client issues a real OAuth access token (sub: anon@xxx) for an unidentified visitor via POST /anonymous/token, called directly from the browser so Auth0 can set its own session cookie. Contrasts a genuinely public catalog endpoint against a JWKS-verified cart endpoint, then hands off to a known user with zero extra code on the redirect.
POST /anonymous/tokenTransparent cookie modeJWKS-verified anon@ tokenPost-Login Action handoff
Open demo →Organizations & B2B
Multi-tenant login, invitations, and org-scoped access for B2B SaaS.
Organizations — B2B Login
Auth0 Organizations for B2B multi-tenancy: the organization parameter travels on the login request itself, landing as an org_id claim on the session. Covers direct member login into a pre-provisioned org, and the invitation flow — a Management-API-created invitation link that signs up a new user, verifies their email, and assigns org-scoped roles in one Auth0-hosted step, no follow-up API call from this app.
organization on loginInvitation-based signupOrg-scoped rolesorg_id claim
Open demo →RBAC & Permissions on Access Tokens
A resource server with RBAC and "Add Permissions in the Access Token" enabled mints a real permissions claim on the access token, and this demo's own API routes actually check it before allowing a request — the one place in this suite an authorization decision is made on more than just session presence. The org-context switch shows why tenant-wide and org-scoped role assignments are separate Auth0 objects: the same user's permissions genuinely narrow when authenticated through an Organization with a different role assigned.
permissions claimReal 403 on missing permissionOrg-scoped vs tenant-wide rolesEnable RBAC + Add Permissions toggles
Open demo →Fine-Grained Authorization
What a token proves versus what it's allowed to do — moving the decision out of the token and into a real ReBAC check at the gateway.
FGA as an API Gateway Enforcement Point
A real Cloudflare Worker gateway in front of a real OpenFGA store — the access token carries no permissions claim at all; every allow/deny decision happens out-of-band, at the gateway, against a live Check call. ReBAC via team membership shows one tuple change can flip access across many resources with zero code change. A gateway outage renders as "unavailable" (503), never a false deny — fail-closed is a real, tested design decision, not just a claim.
OpenFGA Check at the gatewayReBAC via team membershipFail-closed (503 ≠ deny)No permissions claim on the token
Open demo →Self-Service Account Management
The user managing their own factors and profile directly, via Auth0's real My Account API.
My Account API — Factor Management
Auth0's real self-service /me/v1/ API, not the Management API with a user-scoped token — driven by Auth0's own official @auth0/universal-components-react UI (<UserMFAManagement />), not hand-rolled WebAuthn/OTP forms. A generic backend proxy mints a narrowly-scoped access token per request via a raw refresh-token exchange, since the Next.js SDK's getAccessToken() cannot mint a token for a different audience than login requested. The real tenant does enforce MFA step-up for an already-enrolled user, and /me/v1/profile has no working self-service scope at all on this tenant — both confirmed live, not assumed.
/me/v1/authentication-methodsOfficial UserMFAManagement componentRaw refresh-token exchangeReal MFA step-up enforcement
Open demo →Alternate Runtimes
The same flows, on different infrastructure — what actually changes and what doesn't.
Hono on Cloudflare Workers
A real, separately-deployed confidential Auth0 client running on Cloudflare Workers via @auth0/auth0-hono, compared against this suite's Traditional and BFF demos. Same OIDC flow, but a stateless encrypted-cookie session by default (no database) and an edge runtime instead of Node.js serverless — both genuinely different tradeoffs, not just a different host.
@auth0/auth0-honoStateless cookie sessionEdge runtime (Workers)One middleware call
Open demo →Hono on Deno Deploy
The same @auth0/auth0-hono middleware as the Cloudflare Workers demo, deployed instead to Deno Deploy — a third genuinely different runtime and vendor. Dependencies resolve straight from the npm registry via npm: specifiers, no node_modules or bundler step, and the SDK's Node compatibility needs (async_hooks) work with zero opt-in compatibility flag, unlike Workers' explicit nodejs_compat requirement.
@auth0/auth0-hononpm: specifier resolutionDeno Deploy isolateNo compat flag needed
Open demo →