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
25 posts.
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 and external identity bridging - 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.