Sign in with Microsoft Entra ID
Let people in your Microsoft tenant connect to an MCP server with their work account, and forward that person's token to an API
Sign in with Microsoft Entra ID
Use this when people in your organisation should open an MCP client, sign in with their Microsoft work or school account, and call an API as themselves. RequestRocket checks the Entra access token on the way in. A passthrough target credential sends that same token to the API. The API sees Alice's token for Alice and Bob's token for Bob. RequestRocket does not substitute a shared secret.
What you need
- An Entra app registration in your tenant, restricted to accounts in that directory
- An API that accepts the access token that app issues (the token
audis your app, not Graph) - An MCP server whose inbound credential is IdP Verify, with OAuth discovery turned on
- A target credential of type passthrough
- An MCP client that lets you enter an OAuth client id. Claude's custom connector calls this Use your own OAuth client
Entra does not accept a Client ID Metadata Document or Dynamic Client Registration. Claude's other two OAuth client choices (Use Claude's published identity and Register automatically) will not complete sign-in against Entra.
1. Register the Entra application
Create a single-tenant app
In the Microsoft Entra admin center, go to App registrations → New registration.
| Setting | Value |
|---|---|
| Supported account types | Accounts in this organizational directory only |
| Redirect URI platform | Web |
Add the redirect URIs for the clients you will use. For Claude:
https://claude.ai/api/mcp/auth_callbackhttps://claude.ai/api/mcp/oauth/callback
Copy the Application (client) ID and the Directory (tenant) ID.
Allow a public client
Under Authentication, set Allow public client flows to Yes. Claude and similar clients use authorization code with PKCE and do not send a client secret. Leave the connector's client secret blank.
Expose an API scope
Under Expose an API:
- Set the Application ID URI to
api://{client-id}. - Add a scope, for example
access, and admin-consent it for the tenant.
The scope string callers request is api://{client-id}/access.
Issue v2 access tokens
Open Manifest and set accessTokenAcceptedVersion to 2. Save.
With that value, a token for your API has:
| Claim | Value |
|---|---|
iss | https://login.microsoftonline.com/{tenant-id}/v2.0 |
aud | Your client id, or api://{client-id} |
Decode a token from a test sign-in and copy iss and aud exactly. Those two strings are what IdP Verify compares. Do not guess them.
Requesting https://graph.microsoft.com/User.Read, or https://graph.microsoft.com/.default, makes Entra issue a Graph token. That token is the wrong audience for this credential, and signature checks against it fail. Keep the scope on the API you exposed.
2. Create the target
Create a target whose base URL is the API that should receive the caller's token. Tool paths are appended to that base URL.
Create a target credential:
| Field | Value |
|---|---|
| Type | Target |
| Auth type | Passthrough |
| Secret | {} |
Passthrough copies the inbound Authorization header onto the upstream call. It does not store an upstream password. Rules, meters, overrides, and transforms do not see that header. It is restored immediately before the outbound request, so a transform cannot exchange it for a different token.
3. Create the IdP Verify credential
Create a proxy credential with auth type IdP Verify.
| Field | Value |
|---|---|
| Signing algorithms | RS256 |
| Issuer | https://login.microsoftonline.com/{tenant-id}/v2.0 |
| Audience | The aud value from a real token (client id or api://{client-id}) |
| JWKS URI | https://login.microsoftonline.com/{tenant-id}/discovery/v2.0/keys |
| Scopes | api://{client-id}/access |
| Publish OAuth discovery | On |
Discovery is what sends Claude to Entra. With it on, an unauthenticated call returns 401 and protected-resource metadata whose authorization server is the issuer above. With it off, clients are not offered a sign-in; they must already possess a token this credential can verify.
The issuer on the credential is both the expected iss claim and the authorization server URL published to clients. It has to be the v2.0 issuer. A Graph token's issuer (https://sts.windows.net/{tenant-id}/) will not match, and Entra's v2 metadata is what MCP clients need in order to find the authorize and token endpoints.
Single-tenant registration already refuses accounts from other directories. You can also set required claims to { "tid": "{tenant-id}" } so a token from another tenant is rejected even if the issuer string were broader.
4. Create the MCP server
Create the MCP in direct mode and attach:
- the target
- the passthrough target credential
- the IdP Verify proxy credential
Give it an alias if you want a stable URL:
https://{region}.requestrocket.com/mcp/{alias}Paste an OpenAPI 3.x document whose servers[0].url matches the target base URL, then enable the operations people should be able to call. Each tool call is a request to that API, carrying the signed-in user's bearer token.
5. Connect Claude
In Claude, add a custom connector and paste the MCP URL.
| Claude setting | Value |
|---|---|
| Authentication | Sign in now |
| OAuth client | Use your own OAuth client |
| Client ID | The Entra Application (client) ID |
| Client secret | Leave blank |
Claude reads the protected-resource metadata, sends the user to Entra with your client id, and stores the resulting access token. Later tool calls send Authorization: Bearer to RequestRocket. IdP Verify checks the signature, issuer, and audience. Passthrough forwards that header. The API authorizes the Microsoft user named in the token, which is what keeps one person from receiving another person's data.
Microsoft Graph
GET https://graph.microsoft.com/v1.0/me needs a token whose audience is Graph and whose permissions are delegated to that user. That is a different token from the one IdP Verify can accept.
| Approach | Result |
|---|---|
IdP Verify audience set to https://graph.microsoft.com or 00000003-0000-0000-c000-000000000000, passthrough to Graph | The gateway rejects the call. Graph access tokens are not guaranteed to be standard JWTs, and many include a nonce header that makes signature verification fail. The same limit is documented for JWT Verify. |
| A verifiable token for your own app, passthrough to Graph | Graph rejects the call. The audience is your app, not Graph. |
| A request transform that runs the on-behalf-of exchange | The transform never receives the inbound Authorization header, so it has no user token to exchange. |
| Target credential OAuth 2.0 client credentials against Graph | Graph accepts the token, but there is no user. /me does not apply. Every caller shares the application identity. |
To give each person their own Graph data through this MCP, the token Entra issues for sign-in has to be one RequestRocket can verify, and something in front of Graph has to exchange that token for a Graph token. RequestRocket does not do that exchange. Point this pattern at an API that trusts your Entra app directly.