Custom Token Exchange

Early Access

RFC 8693 · Exchange any external token format for Auth0 AT + ID Token + RT · Auth0 Action validates and maps identity

Custom Token Exchange Flow

External Partner JWT

Auth0 /oauth/token

CTE Action validates + setUser()

Auth0 AT + ID Token + RT

The external token can be any format — JWT, SAML, arbitrary string. The Auth0 Action is responsible for validation and identity mapping. No browser redirect; no Universal Login. The result is a full Auth0 session.

External Partner JWT — edit claims

name

role

Issuer is fixed at https://partner-idp.demo and the token is HS256-signed with the same secret the Auth0 Action uses to verify it.

Note: the email must not belong to an existing Auth0 user. The Action maps the external identity by creating a new Auth0 account. Use an address that has never been registered on this tenant — e.g. newpartner@atko.email.

What this pattern demonstrates

Any token format accepted— the external token can be a JWT, SAML assertion, or arbitrary string. The Auth0 Action owns validation entirely; Auth0 enforces nothing about the incoming format.

No browser redirect— unlike a standard Authorization Code Flow, CTE is a server-side token endpoint call. The user never sees Universal Login. This makes it suitable for system-to-system authentication (external IdP federation, migration scenarios, device attestation).

Full Auth0 session issued— on success, Auth0 returns an AT, ID token, and optionally a refresh token. The application gets a complete Auth0 identity for the user, even though that user authenticated via an external system.

Security responsibility— Auth0 explicitly places validation on the implementer. The demo Action verifies the HS256 signature and the issuer URI; a production Action would verify against a public key from the partner's JWKS endpoint and enforce expiry.