OAuth

OAuth lets customers connect to your MCP experience using your existing sign-in system instead of requiring a separate customer key. The customer authenticates with the identity provider your product already uses, and Mitu associates that authenticated identity with a customer record.

This keeps your existing customer accounts at the centre of the relationship. Customers continue signing in through your product’s identity system, while their AI client gains access to the capabilities you have made available through MCP.

How OAuth customer identity works

When an MCP-compatible AI client connects to an operation that requires authentication, the customer is directed through your existing OAuth sign-in flow. After authentication succeeds, Mitu uses the resulting identity to create or resolve the customer associated with that connection.

The identity provider’s stable subject identifier, sub, is used to associate subsequent sign-ins with the same underlying identity. This gives Mitu a customer record it can use when the AI agent acts on that person’s behalf.

The resulting customer can then be associated with other capabilities you choose to provide, such as Agent Wallets. Those capabilities remain separate from authentication and are not created simply because the customer signed in.

Customer records created through OAuth

A customer arriving through OAuth uses the authenticated identity to establish the corresponding Mitu customer record. The identity provider’s sub gives you a stable value that can map the Mitu customer back to the account your own application already knows.

For example, customer creation activity associated with OAuth can identify the source and customer reference:

{
  "source": "oauth",
  "client_reference_id": "auth0|68f3c2a1b9"
}

Your application should continue using its own customer database as the source of truth for account information and permissions. The Mitu customer record exists so activity through MCP, Agent Wallets and other platform capabilities can be associated with that authenticated customer.

Existing authorisation still applies

OAuth authentication identifies the customer but does not bypass your application’s existing authorisation rules. When Mitu calls an operation that requires customer authentication, the signed-in customer’s access token can be forwarded to your API so your backend can continue enforcing the same permissions, account state and entitlement checks it already uses for other clients.

This means your AI integration does not need a separate customer-permission system. Your backend continues deciding what the signed-in customer is allowed to do, while Mitu provides the MCP connection and customer context used by the AI client.

Customer authentication is also separate from Request verification. Your backend should verify that the request came through Mitu before trusting Mitu-specific request context, while the forwarded customer token is used for your existing customer authentication and authorisation.

OAuth does not create an Agent Wallet

Keeping these operations separate means you can use OAuth with customers who only need access to your existing product capabilities as well as customers who later receive Agent Wallets.

See Agent Wallets for wallet issuance and ownership.

API-created customers and OAuth

Choose a consistent identity strategy when the same customer can be provisioned through your backend and also connect through OAuth. Your goal is for both paths to resolve to the same person rather than creating unrelated customer identities for a single account.

If your product primarily uses OAuth for AI-client connections, you do not need to create every customer in advance simply so they can sign in. Allow the OAuth flow to establish the Mitu customer when the customer first connects, then use the resulting customer record for any capabilities you need to add later.

If you also provision customers through the Customer API, make sure the identifiers used by your integration align with the customer mapping supported by your OAuth configuration. Do not assume that two independently created records will automatically be merged.

Connect from an AI client

Once OAuth is configured, customers can connect your MCP endpoint from compatible AI clients and authenticate using their existing account. Clients that support MCP OAuth can discover the authentication flow and direct the customer through sign-in when access to a protected capability requires it.

The exact OAuth discovery and protocol endpoints are documented under MCP authentication. Keep those protocol details there rather than duplicating them across the customer documentation.

Related