> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.mitu.ai/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mitu.ai/_mcp/server.

# Authentication

MCP tools can be public or require an identified customer. When customer authentication is required, Mitu needs to know which customer the AI agent is acting for before the operation can be used.

You can identify customers using a Mitu customer key or your existing OAuth identity provider. Both approaches establish customer context for the connection, but they differ in how the customer receives and proves that identity.

## Authentication methods

| Method       | How the customer connects                                                             | Best suited for                                                 |
| ------------ | ------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Customer key | The customer provides an `mcpk_...` credential issued for their Mitu customer record. | Products where you provision access directly.                   |
| OAuth        | The customer signs in using the account they already have with your product.          | Products with an existing customer identity and sign-in system. |

You can support the method that fits your product, and protected endpoint definitions use `requires_auth` to indicate that customer identity is required.

## Customer keys

When you create a customer through the Customer API, Mitu can return an `mcpk_...` customer key associated with that customer. The customer provides this credential to a compatible AI client when connecting to your MCP endpoint.

```http
x-api-key: mcpk_3a6f9d2a...
```

Where supported, the credential can also be supplied as a bearer token.

```http
Authorization: Bearer mcpk_3a6f9d2a...
```

A customer key authenticates one customer to the MCP connection. It is different from the merchant API key your backend uses to call the Mitu API and does not give the customer access to your Mitu account or administrative wallet operations.

> **Keep merchant and customer credentials separate**
>
> `sk_test_...` and `sk_live_...` are server-side credentials for your business. `mcpk_...` identifies an individual customer connecting through MCP. Never provide a merchant API key to a customer or place it in an AI client.

See [Customer keys](/platform/customers/customer-keys) for the customer credential lifecycle.

## OAuth

OAuth lets customers connect through the identity system your product already uses. Instead of receiving a separate customer credential, the customer adds your MCP endpoint to a compatible AI client and signs in using their existing account.

Mitu participates in the OAuth flow required by the AI client and associates the authenticated identity with the corresponding customer record. Once the customer is signed in, protected tools become available in the context of that customer.

When Mitu forwards a protected operation to your API, the signed-in customer's access token can also be forwarded so your existing backend continues applying its normal authentication, authorisation and entitlement rules.

OAuth therefore identifies the customer without replacing your application's own access-control model. Your backend remains responsible for deciding what the authenticated customer is allowed to do.

See [OAuth](/platform/customers/oauth) for customer identity and [Customers](/platform/customers/overview) for the customer model.

## Public and protected tools

Use `requires_auth` on an endpoint to determine whether customer identity is required.

Public operations are useful for capabilities that do not depend on a customer account, such as retrieving publicly available information. Protected operations should be used when your API needs to know which customer is making the request or when the operation depends on account-specific data or permissions.

Authentication should reflect the requirements your product already has rather than making every MCP tool protected by default.

## Authentication and request verification

Customer authentication and request verification solve different problems. Customer authentication tells your application **who the AI agent is acting for**, while request verification tells your backend **whether the request actually came through Mitu**.

When your API receives a customer-aware request, verify the Mitu request before trusting Mitu-specific customer context. If OAuth is used, continue validating and authorising the forwarded customer access token according to the same rules your backend already applies.

See [Request verification](/platform/security/request-verification) for the request verification contract.

## Choosing an authentication method

Customer keys are useful when your business explicitly provisions AI access and wants to issue a credential directly to a customer. OAuth is usually a better fit when customers already have accounts and should connect through the same sign-in experience they use elsewhere in your product.

Both methods ultimately provide customer identity to protected tools. The choice does not require you to rewrite the underlying API operations you make available through MCP.

## Related

#### [Customers](/platform/customers/overview)

Understand the customer identity model.

#### [Customer keys](/platform/customers/customer-keys)

Understand the `mcpk_...` customer credential.

#### [OAuth](/platform/customers/oauth)

Connect customers using your existing identity provider.

#### [Request verification](/platform/security/request-verification)

Verify requests before trusting Mitu-specific context.