Auth0 alternatives for user, agent, and delegated identity

A service calls your API with an Auth0 machine-to-machine token. The logs show your application, not the person who asked. You switch on On-Behalf-Of exchange so the downstream API still sees the user. The agent then needs Gmail. Auth0 has not issued a Gmail token. Three identities just got conflated, and only two of them live in Auth0.

This post separates user identity, agent identity, and delegated identity, and shows which one a provider credential actually is.

Three identities Auth0 can express

The On-Behalf-Of docs draw the line. Client Credentials means the application acts as itself. The user who started the request is gone. The downstream API sees the application. On-Behalf-Of token exchange takes a user token and mints a new token for the next API, still carrying that user. Scopes follow the user's roles.

Custom Token Exchange is for a token you already have, including delegated authorization where a service or agent acts for a user. It is on B2C Professional, B2B Professional, and Enterprise. The actor and the subject can both be recorded. That is still an Auth0 token for an API you registered. It is not a Gmail or Salesforce refresh token.

The pricing page lists Free at $0 up to 25,000 monthly active users. Essentials starts at $35 a month on B2C and $150 on B2B, at a 500 MAU slider. Professional starts at $240 on B2C and $800 on B2B, again at 500 MAU. Those are starting prices at that slider, not a ceiling. Machine-to-machine tokens included are 1,000 on Free and Essentials and 5,000 on Professional. More M2M tokens are an add-on. The 250,000 token add-on is $1,000 a month on the published table.

Where each identity belongs

Use a user token when a person is present and the API should enforce that person's roles. Use client credentials when a backend job is the actor and no user should be implied. Use On-Behalf-Of or Custom Token Exchange when a middle service must prove both "which user" and "which app." Authentication platforms compares products in this family.

None of those flows grant the third-party API credential. If the agent must call a provider your tenant connected, you need that tenant's token, stored and attached at call time. Multi-tenant OAuth is the map. Credential brokering is why the model should see the user id and not the provider secret.

What the agent presents on the provider call

Swytchcode does not replace Auth0 for your own API. It sends the provider call after you enable the method. The credential comes from swy auth connect, not from the Auth0 access token. A policy can require an approval when the call is on behalf of a user and the amount is high. On the October 2026 pricing page, approval starts on Business. Free and Pro are allow and deny only. If you need "the user asked, the agent acts, a person confirms," that confirmation is the approval step, not a second Auth0 token.

Policy as code can key off fields in the call. Put the user id in the arguments if the provider body has a place for it. Do not stuff the Auth0 token into the provider request and hope the provider understands it.

Trace one support request. The user is logged in, so you have a user token. Your API calls a billing service with On-Behalf-Of, so the billing service still sees the user. An agent then offers to open a ticket in the customer's Jira. The Auth0 token will not authenticate to Jira. The customer connected Jira last week, and that refresh token is the third identity: the tenant's grant to a third-party API. Log all three on the action. User id from Auth0. Application id from the client. Provider account id from the connected credential. If a person must confirm the ticket, that confirmation is an approval on the provider call. It is not another token exchange. Mixing them up is how a machine token gets treated as the user's consent to write in Jira.

Identify the actor, then connect the provider

Follow this step to install the CLI. Use one of these.

npm install -g swytchcode

irm https://cli.swytchcode.com/install.ps1 | iex

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Confirm the install, then start the project. Keep Auth0 on your own API.

swy --version
swy init

Search the registry for the third-party API and add methods from the local list.

swy search <provider>
swy get <name from search>
swy list methods
swy add <canonical_id from swy list methods>

Connect the provider before the agent can spend with that token. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs.

swy auth connect <provider>
swy policy validate

Let Auth0 say who the user is and which app is calling. Let a connected provider credential say which tenant API the agent may call. Log the user id, the application id, and the provider account id on the same action.

Related reading

• A credential per customer. Delegated Auth0 tokens and provider tokens are different.
• Credential brokering. The model can know the user id and still not see the provider secret.
• Managed OAuth providers. Hosted OAuth for third-party APIs, not for your login page.
• Human approval. Confirm a delegated write before it runs.

FAQ

Does client credentials preserve the user?

No. Auth0's docs say the application authenticates as itself and the user context is lost. Use On-Behalf-Of token exchange when the next API must see the user.

How many machine-to-machine tokens are included?

The pricing table lists 1,000 on Free and Essentials, and 5,000 on Professional. Additional tokens are a paid add-on. A 250,000 token pack is $1,000 a month on the published monthly table.

Is Custom Token Exchange available on Free?

No. Auth0 says it is on B2C Professional, B2B Professional, and Enterprise. On-Behalf-Of is documented separately and is for your own APIs in the chain.

Can an Auth0 token call Gmail for the user?

Only if Gmail is somehow using that token, which it is not. Gmail needs the OAuth token the user granted for Gmail. Store that token as a provider credential and keep the Auth0 token for your API.