# Token Vault: no tokenset stored at login, exchange fails with federated_connection_refresh_token_not_found EU public cloud tenant (prod-eu-2), Free plan. We're building the documented Auth for GenAI scenario: an MCP server protected by Auth0 calls a M

Get Help
1

Token Vault: no tokenset stored at login, exchange fails with federated_connection_refresh_token_not_found

EU public cloud tenant (prod-eu-2), Free plan.

We’re building the documented Auth for GenAI scenario: an MCP server protected by Auth0 calls a Microsoft Entra-protected custom API (api://<app-id>/access_as_user, not Graph) on the user’s behalf via Token Vault access-token exchange.

Login through Microsoft works, and we verified the upstream authorize request includes offline_access plus the custom scope. Microsoft returns access and refresh tokens: after each login they appear in the user’s identities array. But the docs say a vault-enabled connection should store them in a tokenset instead, and that never happens. connected_accounts.active is true on the connection (set before login), yet the exchange always fails with federated_connection_refresh_token_not_found.

We tried three strategies:

  • waad: setting options.scope breaks login itself (AADSTS28003, empty scope sent at code redemption)

  • oidc: login OK, upstream tokens discarded entirely

  • custom oauth2: login OK, tokens stored on the identity, never in the vault

Also, the “Microsoft Entra” social connection from the Microsoft integration guide doesn’t exist in our catalog, and the Management API rejects its strategy name.

Questions:

  1. Is login-time tokenset storage supported for oidc/oauth2 strategy connections, or only for first-party connectors?

  2. Is the “Microsoft Entra” connector gated by plan, region, or rollout? How do we get it?

  3. Is there a supported way today to get an Entra token for a custom API through Token Vault?

Happy to share tenant name, log entries, and trace IDs privately. The setup is scripted and reproducible in minutes.

3

Hi @aleksander.chernyavs

Welcome to the Auth0 Community!

I can see that you are having issues in building an Auth0 hosted MCP server application which makes calls to an Entra-protected custom API while using the Token Vault Access Token Exchange.

It appears that you are running up against the architectural boundaries of how the Auth0 Token Vault, the Connected Accounts for Token Vault feature set, and Microsoft Entra’s proprietary OAuth2 deviations operate at the edge.

Token Vault’s automated login-time tokenset storage is strictly supported only for native, first-party Marketplace connectors.

  1. In Auth0, the “Connected Accounts for Token Vault” capability relies on first-party templates (like Google, GitHub, Slack, etc.) where Auth0’s backend completely controls the upstream /token exchange logic.

  2. When you configure a custom oidc or oauth2 connection, Auth0 relies on a generic fetchUserProfile script (where you only return user claims). Because custom connections don’t pass control of the token lifecycle back to a pre-built Auth0 integration module, Auth0 does not auto-populate the tokenset in the Token Vault during a standard /authorize login flow. Instead, the tokens are simply appended to the identities array in the standard OIDC format, which lacks the vault’s active refresh capability.

To populate a custom connection’s tokenset in the vault, you must bypass the standard interactive user login flow and utilize the Connected Accounts API (via the My Account API) to explicitly link the account.

The “Microsoft Entra” connector you saw in the AI/Agent documentation is a specialized connector currently rolling out alongside the “Auth0 for AI Agents” early-adopter/preview program

  1. The standard enterprise connector is called waad (Windows Azure Active Directory). The new microsoft-entra strategy is built specifically to support the Token Vault’s automated tokenset storage natively.

  2. Because your tenant is on the Free plan (EU-2), this specialized AI-agent connector is not yet visible in your catalog. It is progressively rolling out to Enterprise-tier tenants and those explicitly enrolled in the developer preview.

  3. When you tried using the standard waad connection with custom options, it failed (AADSTS28003) because the legacy Microsoft Enterprise connection strategy does not format the token redemption payload in a way that respects the offline_access scope for custom APIs.

There a supported way today to get an Entra token for a custom API through Token Vault but because Microsoft Entra does not communicate through RFC 8693 (standard OAuth Token Exchange) natively, you have to use a specific structural pattern to bridge the gap.

To get an Entra token for your custom API (api://<app-id>/access_as_user) through Auth0’s Token Vault today, use one of the two methods below.

Method A: The Custom oauth2 Connected Accounts Flow (Recommended for Token Vault)

If you want to keep using the Token Vault, you must configure your custom oauth2 connection and link it via the Connected Accounts flow rather than a standard login.

  1. Configure the Connection: Keep your custom oauth2 connection with connected_accounts: { active: true }.

  2. Explicitly request the custom scope: Ensure your connection’s options.scope is set strictly to:
    openid offline_access api://<your-entra-app-id>/access_as_user

  3. The User Connection Flow: Do not have the user log in using this connection. Instead, log the user in using a standard connection (e.g., username/password), and then have your app trigger the Connected Accounts linking flow:

    • Redirect the user to the /connect endpoint for your custom connection.

    • This forces an active, explicit consent screen on the Microsoft side where the user authorizes your custom API scope.

    • Once completed, Auth0 will write the connected_accounts entry to the user profile and successfully store the refresh and access tokens in the tokenset vault.

Method B: Use a Gateway-Level Token Exchange (Industry Best Practice)

If you are building an MCP (Model Context Protocol) server or gateway for GenAI, the emerging production pattern is to use a gateway like AgentGateway.

Entra requires an On-Behalf-Of (OBO) flow (urn:ietf:params:oauth:grant-type:jwt-bearer with requested_token_use=on_behalf_of) rather than standard RFC 8693 exchange.
Instead of relying on Auth0’s internal Token Vault to negotiate with Entra, your MCP server/gateway takes the user’s incoming Auth0 ID/Access Token and immediately performs an Entra OBO token exchange directly with Microsoft’s token endpoint (https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token) to obtain the downscoped access_as_user token on the fly. This keeps your MCP architecture completely standard, highly performant, and fully compatible with the Auth0 Free plan.

Kind Regards,
Nik