16 posts.
Four separate follow-up posts are now folded into the main guide instead of sitting as bolted-on updates at the bottom - two new grant types for devices with no browser of their own, and two new use cases worth building around: Token Vault and Session Delegation.
Every SaaS company with a support team eventually needs a 'log in as this customer' button, and most build it badly. Auth0's new Session Delegation feature is a paved path for it - an audited, time-boxed session with an act claim naming the agent. Wiring up a genuine one meant fixing two failures Auth0 never surfaces as an OAuth error, then a bug entirely of my own making.
Verification level answers who a persona provably is, established once and true forever. Session assurance answers something else entirely - how strongly the current login just proved it - and it has no business being stored as a fact at all.
Auth0's Manage Sessions with Actions APIs let a Post-Login Action set a non-persistent cookie mode and short expiry on the Authorization Server's own session. Getting a genuinely ephemeral login end-to-end took matching that on the app's own session too, and an access token that turned out not to be a JWT.
Auth0's Token Vault lets your app call Google or GitHub APIs with a user's own consent, without the user's password ever touching your app. Getting it working end to end took five separately-gated prerequisites, each with its own unrelated-looking error message.
A company registry needs three things a subscription service doesn't: a public entry anyone can search, a governance role distinct from day-to-day admin, and proof that whoever holds that role is who they say they are.
An anonymous session's cookie and its metadata are both set once, at the moment the session is created, and neither one changes again for the rest of that session's life. That single fact reshapes how you have to track state across the handoff into a known identity.
Auth0 published a guide for running a confidential client on Cloudflare Workers with @auth0/auth0-hono. I built the guide's example for real and hit three things it doesn't mention — a middleware default that locks down every route, an undocumented Node API dependency, and a session model that changes what revoking a session actually means.
Auth0's Device Authorization Grant lets a CLI tool or smart TV authenticate a user without a browser of its own. Getting it working meant hitting an undocumented requirement — the client has to be a native, OIDC-conformant public client, not the confidential regular_web type used everywhere else in Auth0.
Building a genuine Client-Initiated Backchannel Authentication demo against a real Guardian push notification - not a simulated approver inbox - turned up two bugs of my own making, then a Rich Authorization Requests upgrade that changes what the push notification is actually allowed to say.
Auth0's session_transfer_token was built for handing a session from a native app to a web app on the same domain. Point it at two genuinely different Auth0 domains in the same tenant and the audience parameter has an undocumented requirement - get it wrong and Auth0 doesn't error, it silently hands you a plain access token instead.
When a user taps 'Open in browser' inside your mobile app, they get asked to log in again. Auth0's Native-to-Web SSO solves this by exchanging a refresh token for a short-lived session transfer token that the web app can consume without any re-authentication.
Every Auth0 session and token option in one live demo - Traditional Web App, SPA with DPoP, BFF with Multi-Resource Refresh Tokens, SSO isolation, On-Behalf-Of, Custom Token Exchange, and a unified profile view that correlates all of them at the Authorization Server layer.
Auth0 gives you a lot of knobs to turn when it comes to sessions and tokens. This post maps out every option - including RFC 8693 token exchange flows for service delegation, external identity bridging, and customer-support impersonation - and shows how they work together for different application types.
A server-rendered web app is the simplest of Auth0's session patterns to reason about, right up until you try to revoke a session and find out the browser didn't get the memo. Here's how to build one properly.
Auth0 has launched native support for Global Token Revocation and Okta's Universal Logout functionality. This means that Auth0 applications now natively support the ability for federated Okta customers to automatically revoke all of the users sessions and tokens when Identity Thr