Demo Script

What to look for

• Session Management API returns both sessions with distinguishing device metadata.
• Revoking from browser A actually terminates browser B — Back-Channel Logout, not just a client-side redirect.

What to look for

• Renaming a device does not wipe its other metadata fields (browser/os/ip/captured_at) — the PATCH merges rather than replaces.
• Revoking deletes the refresh token, so the other browser can’t silently mint a new access token afterward.
• This device list is scoped to the SPA application only — it won’t show devices from the Traditional or BFF demos even though they share a user.

What to look for

• Revocation gap in the polling log: the timestamp between last-success and first-failure is one poll interval (~2s), not the access token lifetime (~5 min).
• Error on the failed tick: invalid_grant — Auth0 rejected the refresh token exchange because the server-side record was deleted.
• The access token displayed in the ID/AT panel was still valid at the time of revocation — ORT kills the session before that AT would have naturally expired.
• Comparison card at the bottom: DPoP stops token replay; ORT stops the post-revocation grace period. They solve different parts of the problem.

What to look for

• MRRT policy comparison card shows the structural difference: BFF has refresh_token.policies[], SPA has nothing.
• Exchange ledger: each row shows RT before, audience, RT after. The chain badge on row 2 confirms the rotation lineage is continuous.
• Unauthorized audience test: Auth0 enforces the policy — the actual aud is NOT the requested audience.
• Tokens never appear in browser storage or network responses — only the session cookie reaches the browser.

What to look for

• The sidebar, not /profile, is the single place sessions/devices are always visible — it's mounted in the root layout, so it's on every page in this suite, including the homepage.
• /profile is trimmed to what genuinely doesn't fit a narrow column: identity editing and the Fingerprint Smart Signals/visit-history detail panel.
• Fingerprint's visitorId is captured once, in the sidebar (the only place mounted on every render) — /profile reads the same value back from the session's refresh_token_metadata instead of re-running the agent, avoiding a second identification call for the same device.
• One session card groups Traditional + BFF because they share an Auth0 AS session — the clients[] array on the session record is the source of truth, not which URL you happen to be on.

What to look for

• sso:false is set on the Auth0 client record via Management API — not a runtime prompt parameter. The isolation is permanent and applies to every login, not just this session.
• The sidebar shows two session cards for the same user because they have different Auth0 session IDs — the unified view groups by session, not by user.
• Revoking the High Trust session leaves the Traditional session completely untouched — there is no shared state to cascade through.
• Use case: admin panels, payment flows, medical records — any surface where re-authenticating on every access is a compliance or security requirement regardless of existing SSO state.

What to look for

• sub is identical across both token panels — the STT transfers the identity, not just a hint of it.
• The STT countdown: 60 seconds is the entire usable window. If you wait too long before clicking Authorize, Auth0 rejects it.
• The STT is gone after step 4 — single-use means a second /authorize with the same token returns an error.
• The web session has no refresh token (allow_refresh_token: false on the web target client) — it is a forward-only transfer, not a persistent grant.

What to look for

• issued_token_type is the only field that distinguishes a real STT from Auth0's silent fallback to a plain access token — this demo surfaces it explicitly because the failure mode otherwise looks like an ordinary 200 response.
• The STT audience must name the source domain (Brand A's) — passing the target domain doesn't error, Auth0 just silently mints a plain token instead.
• prompt=none on Brand B always returns login_required regardless of Brand A's session — two real origins simply can't share one AS session cookie, unlike the High Trust demo where isolation is a deliberate client setting rather than a browser security boundary.

What to look for

• sub is identical in AT1 and AT2 — the user identity is preserved through the exchange.
• azp in AT2 is the middle-tier service client ID, not the user-facing app.
• act claim records the delegation chain: who exchanged the token and on whose behalf.
• The downstream Orders API never sees the original AT1 — it only sees the scoped, delegated AT2.

What to look for

• No browser redirect — CTE is a pure server-side token endpoint call.
• The incoming token format is completely custom (HS256 JWT with a demo issuer) — Auth0 never validates it; the Action does.
• The resulting ID Token contains an Auth0 sub, not the external sub — the Action performed identity mapping.
• If the CTE Profile is not yet created in the dashboard, the error card shows the exact manual step needed.

What to look for

• The stitch happens entirely in the analytics layer (client-side distinct_id merged via identify()) — Auth0 itself has no concept of "anonymous" in this path.
• Only PostHog can power the in-app reporting panel — GA4's Data API has a 24–48h delay and Segment has no queryable Events API.
• See also /demo/anon-sessions (next phase) for the other half of this problem: authenticated API access before login, not analytics attribution.

What to look for

• The catalog call has zero Authorization header; the cart call without a token 401s; the cart call with the anon access token 200s with sub: anon@xxx — three distinct auth modes against one small API surface.
• Session creation is a same-origin relay, not a browser-direct call — confirmed as a real gap with Auth0's product team: the actual POST response to /anonymous/token and /anonymous/logout never carries Access-Control-Allow-Origin on this beta build, only the OPTIONS preflight does, so a browser can never read either response directly.
• Set-Cookie for auth0_anon only ever fires on that one final create call, never on a renewal — confirmed empirically, not assumed. That's exactly why a fresh anon@ sub shows up at login: the relay's session and the sealed session are genuinely different identities, and cart_id (not sub) is what stays continuous across that gap.
• app_metadata.cart_sessions never contains cart contents, only cart_id/session_id/timestamps — also confirmed with Auth0's product team as deliberate design, not a limitation of this demo: metadata is for identifiers, never general data storage.
• The Backend API log reads back the server's own verified record of each call (JWKS-checked sub, not a client-side guess) — the same /api/anon-sessions/cart route visibly serves both an anon@xxx and an auth0|... caller.
• This feature is explicitly beta with real limitations (no Password Reset, Device Code, CIBA, or CTE for anonymous users) and no replay detection on the session token — named directly in the Security Implications section, not glossed over.

What to look for

• The Guardian enrollment ticket URL is meant to be opened as a link, not fed into Guardian's own in-app QR scanner — that exact mismatch is what broke it during development (the in-app scanner expects a different payload format).
• Standard mode's binding_message is one opaque string the approver has to trust; HRI mode's authorization_details are itemized fields Guardian renders natively — same underlying transaction, genuinely different trust properties.
• HRI requires the Guardian schema type (urn:auth0:schemas:authorization-details:v1:user-profile) to be registered on the resource server first — Auth0 rejects unregistered types with invalid_authorization_details rather than silently ignoring the field.
• No persisted consent — a repeat request seconds later still prompts fresh; Auth0 never caches a prior approval.

What to look for

• This is the one demo in the whole suite with no cookie session dependency at all — the initiating page genuinely doesn't know who the user is until the second screen resolves it, so the sidebar's identity header stays blank here until you sign in somewhere else.
• Auth0 requires app_type: "native" for this grant — the resulting client is public, with token_endpoint_auth_method: "none". There is no client secret anywhere in this flow.
• Device-code phishing is a real, named risk (see the Security Implications section on this page) — an attacker can relay their own code or link to a victim under a pretext.

What to look for

• Same confidential-client model and OIDC flow as Traditional/BFF — the genuinely different axes are session storage (self-contained encrypted cookie vs Firestore-backed) and runtime (V8 isolate vs Node serverless), not the auth flow itself.
• The default session mode has no server-side kill switch — ending a session here means key rotation or waiting out the TTL, not deleting a database row like Traditional/BFF's Back-Channel Logout does.
• Building this surfaced real, undocumented gotchas: the SDK's authRequired option defaulting to true (401'd the homepage until set explicitly), an undocumented nodejs_compat requirement, and Cloudflare rejecting a "future" compatibility date — none of which the original SDK guide mentions.

What to look for

• sub is identical from the ID token through to the final access token, mocked or real — the end user's identity is preserved end-to-end.
• No OAuth consent screen appears anywhere in this flow — the trust decision was made centrally via the admin policy toggle, not per-request by the user.
• The 403 from the toggle comes from the mock IdP's mint call, not from Auth0 — governance is enforced at the point of assertion issuance, a separate boundary from Auth0's own real XAA policy.
• The redemption step always makes the real call first — once Auth0 ships Requesting App support, the "🧪 Mocked" badge should flip to "✅ Real Auth0" with no code changes on this end.
• Compare the "With XAA" vs "Without XAA" panel above the demo — same end goal, four steps and no redirect vs. a traditional OAuth consent dance repeated every time.

What to look for

• act claim shape: { sub, sub_profile: "human", role: "support" } — richer than the plain act.sub seen in the OBO demo, since Session Delegation is built for a human actor, not a service.
• The domain-wide "log out first" rule is genuinely surprising the first time you hit it — it blocks on any active session on the domain, not just a session belonging to the subject being impersonated.
• No refresh token is ever issued for the delegated session, and both the AT and the session share a hard, non-configurable 2-hour ceiling.
• The Management API schema for this feature (found empirically, not from the docs) nests everything — mint-side and redeem-side settings alike — under one session_transfer object on the client; Auth0's own error message labels it "Native to Web SSO Configuration," confirming it's the same underlying mechanism as phase 7.

What to look for

• If you originally logged into this app via Google, that column shows "Signed in (profile only)" instead of "Not connected" until you explicitly connect it — being signed in with a provider is not the same as having a Connected Account for it.
• The access token shown is scoped narrowly — calendar.readonly or public_repo — not the same token or scope as this app's own session.
• Disconnect calls a real Management API revocation, not just a local UI toggle — reconnecting afterward requires consent again.

What to look for

• The ephemeral claim comes from a Post-Login Action applied unconditionally to this client — nothing in the browser or login request asserts "treat me as ephemeral."
• No offline_access scope means getSession() on this client can never silently refresh — once the access/ID token expires, re-authentication is the only path back in.
• Idle and absolute deadlines are enforced independently — pausing polling to let idle lapse expires the session well before the absolute cap would have.