40 posts.
A live user hit a broken appeal submission on an error from the exact family the previous post had just spent two sessions solving. It wasn't the same bug - the earlier fix's own assumption didn't hold for a second hop, and two more unrelated bugs were stacked underneath it.
Building out an Auth0 Organizations demo suite with Claude Code, three separate bugs all had the same shape: the verification looked complete, and was still checking a different layer to the one where the failure actually lived.
On-behalf-of token exchange for the apidays demo's MCP server failed with the same generic error no matter what I tried. Six separate, individually correct verification passes across two sessions all checked the wrong property of the one field that mattered.
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.
An adversarial review across two different AI models caught a real OpenFGA semantics bug in the model behind this series, and also produced confident, specific-sounding nonsense that didn't survive being checked. Both outcomes are worth writing up.
The model from this series has humans and businesses as principals, but not agents, and no way to represent a delegation that's been requested but not yet approved. Both turned out to need real additions, not workarounds.
Every delegation in this series so far has been bounded by time. This post covers the other kind: bounded by a dollar figure, or a dollar figure and a category together, checked fresh against every attempted spend rather than a stored running total.
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.
Auth0's Passkey APIs let you build passkey sign-in directly into your own UI instead of redirecting to Universal Login. Here's how that fits alongside Universal Login, what self-service passkey management looks like hand-rolled versus with Auth0's official pre-built components, and one Allowed Origins (CORS) setting worth checking before you go looking for a WebAuthn bug that isn't there.
It's easy to claim an authorisation model is generic. It's more convincing to run the exact same model, unmodified, across media, healthcare, financial services, telco, retail and legal case management, and show the tests passing every time.
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.
The delegated-access series treated the authenticated login as the whole security principal. It isn't quite. The same real person routinely holds more than one login, and an authorisation model that can't tell them apart ends up merging blast radii it shouldn't.
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.
When an anonymous visitor signs up or logs in, their pre-authentication browsing history disappears - invisible to both your identity system and your analytics. This post details how to bridge that gap using PostHog's identity model and the Auth0 callback flow.
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.
Running Auth0 MFA demos with real SMS requires every presenter to have a personal phone enrolled. Auth0's custom-phone-provider trigger lets you route codes to a shared inbox instead, so any team member can run the demo without any per-device setup.
OpenID's Shared Signals Framework and Continuous Access Evaluation Profile went final in August 2025, but Auth0 supports neither natively. This post details a from-scratch reference implementation, and what building it revealed about the gap between a finalised spec and the tooling around it.
The previous post covered the CIBA approval flow for delegated access. This one covers what happens when the five-minute CIBA window closes before the approver responds - and why the answer reveals an important architectural distinction between the delivery mechanism and the approval itself.
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.
The previous post covered how a patient proactively grants a carer access to their record. This post covers the inverse: a user requests access they do not yet have, and the account holder approves it in real time using Auth0's Client-Initiated Backchannel Authentication.
The first post in this series covered why separating the authenticated actor from the account they are acting within matters. This post covers how to build it: the data model, the integration points between Auth0, Auth0 FGA and a standard application data store, and the key flows from delegation grant through to acting on someone else's behalf.
Identity systems are very good at answering one question: who are you? What they are less good at is the follow-up: and who are you acting for? In this post I will look at why separating the authenticated user from the account or person they are acting within is important, what it enables across a range of industries, and how Auth0 and Auth0 FGA address the two complementary sides of the problem.
In part one we built the Auth0 ACUL screens for multi-tenant routing with a hardcoded lookup. In this post I will replace that with a real Cloudflare Worker backed by Workers KV, move to full email-address routing, handle users who exist across multiple tenants, and add Cloudflare Turnstile bot protection to the login screens.
Home Realm Discovery is a well-understood pattern at the network layer, but moving that routing logic inside Auth0's login flow using Advanced Custom Universal Login opens up some interesting possibilities — and a few unexpected challenges.
The Auth0 CLI is a handy tool to help with designing and building your Auth0 experience. It lets you do a number of things including: The Auth0 CLI has a simple interactive logging flow that lets you login as a user and it is powered by the device authorization flow. Unfortunatel
Auth0 supports Twilio out of the box as a phone provider however in many instances Twilio Verify provides a better experience. The out of the box Twilio integration requires the sender to manage all of the phone numbers and Sender IDs that they need. This can be simple if you onl
Auth0 Forms is a tool designed to allow identity flows to be extended with customisable forms and logic, allowing use cases like progressive profiling, policy acceptance, payment collection and more within the hosted login flows you've come to know and love from Auth0. For more d
Auth0 Forms is a powerful tool to extend identity flows with customisable forms and business logic. Forms allows for a hosted secure experience with no need to redirect users to external sites and consistent branding with Universal Login. In this blog post I will talk through how
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
A while ago Okta announced the integration of Okta Workflows with Auth0. Bringing low-code automation to the Auth0 platform. In this blog post I am going to cover the setup steps for the integrations. In another blog post I give an example of deleting inactive users from a one of
Here is a presentation I gave today on passkeys at the Canberra Cyber Conference hosted by AISA.