MCP Enterprise-Managed Authorization Guide

Enterprise-Managed Authorization uses the Identity Assertion JWT Authorization Grant (ID-JAG) defined in draft-ietf-oauth-identity-assertion-authz-grant. Flip implements the MCP client and enterprise IdP roles. You implement the MCP Authorization Server and the MCP server.

Whenever a Flip user's conversation with a custom agent needs tools from your MCP server, the following happens:

1. Ask AI obtains an ID-JAG for the user from the Flip identity provider. The ID-JAG is a signed JWT addressed to your MCP Authorization Server.
2. Ask AI sends the ID-JAG to the MCP Authorization Server's token URL using the urn:ietf:params:oauth:grant-type:jwt-bearer grant, authenticated with the client ID and client secret you issued to Flip.
3. Your MCP Authorization Server validates the ID-JAG, maps the user to an account on your side and returns an access token.
4. Ask AI calls your MCP server with Authorization: Bearer <access token>.

• Your MCP Authorization Server supports the Enterprise-Managed Authorization extension. It must accept an ID-JAG issued by Flip as an authorization grant on its token endpoint, using the urn:ietf:params:oauth:grant-type:jwt-bearer grant type, and return an access token for the MCP server. See Validating the ID-JAG on your side for what this involves.
• Your users have a matching identity on your side. Flip can identify the user to your MCP Authorization Server by their Flip email address or their Flip username (see User identifier). Whichever you choose must be present for every user who should use the MCP server and must be resolvable to an account in your system.

Before the setup can start, the following information needs to be exchanged:

Flip signs the ID-JAG with the same key material it uses for its OIDC tokens (RS256 by default). The JWS header carries the type oauth-id-jag+jwt, as required by the specification. Tokens are valid for 5 minutes.

Decoded example (values shortened, signature omitted):

Flip redeems the ID-JAG with an application/x-www-form-urlencoded POST to your token URL:

Things to note:

• Client authentication uses client_secret_post, i.e. client_id and client_secret in the form body. HTTP Basic authentication (client_secret_basic) and private_key_jwt are not supported.
• No scope or resource parameter is sent with the token request. The granted scopes are carried inside the assertion's scope claim.
• Flip does not follow redirects from the token endpoint and treats any non-2xx response as a failure.

Your response must be a JSON object containing a non-empty access_token string, following RFC 6749 §5.1:

Flip uses the access token as a Bearer token for all requests to the MCP server during the conversation turn. Flip does not refresh the token within a turn; issue tokens that live at least a few minutes.

Your MCP Authorization Server must validate every assertion before issuing an access token. At minimum:

1. Header type: the JWS typ header is oauth-id-jag+jwt.
2. Signature: verify against the keys published at the Flip JWKS endpoint. Resolve it via the discovery document (jwks_uri) and cache the keys, honouring the kid header. Keys rotate.
3. Issuer: iss equals the Flip issuer you agreed on, https://{domain}/auth/realms/{organisation-id}.
4. Audience: aud equals your own issuer identifier, exactly as entered in Flip.
5. Expiry: exp is in the future, iat is not in the future. Allow a small clock skew.
6. Client binding: client_id in the assertion matches the client that authenticated the token request.
7. Replay (recommended): reject a jti you have already seen within its validity window.
8. User resolution: map aud_sub (or sub, if you store Flip's user ID) to an account, and apply your own access policy. Return an OAuth error if the user is not allowed to use the MCP server.

Return standard OAuth 2.0 error responses (invalid_grant, invalid_client, invalid_scope, ...) with a short error_description. Flip forwards status and body to the administrator, which makes configuration mistakes much faster to find.

• Error messages: when saving an MCP connector fails, the console shows the HTTP status and the body returned by the token endpoint. End users in chat only see a generic message; details are not exposed to them.
• Flip cannot hand over tokens for inspection. Production systems do not log tokens or their claims. To debug claim values, log the incoming assertion on your MCP Authorization Server in a test environment.
• Issuer mismatch: check that the setup and the affected users use the customer-facing domain, and that the MCP Authorization Server validates iss against https://{domain}/auth/realms/{organisation-id} for that domain. Testing environments have a different domain and therefore a different issuer than production.
• Audience mismatch: compare the aud claim with the Issuer field in Flip character by character, including scheme and trailing slashes.
• invalid_client: the client ID entered in Flip or the client secret on the connector does not match the registration at the MCP Authorization Server. Re-enter the secret on the connector.
• The tool list cannot be fetched during setup: the administrator saving the connector has no matching identity at the MCP Authorization Server. Repeat the setup as a real user with a valid identifier.
• Access works in one Flip environment but not another: the Flip issuer differs per environment and per organisation, and the MCP Authorization Server must accept each one.

• Enterprise-Managed Authorization on modelcontextprotocol.io
• Full extension specification in the MCP ext-auth repository
• Identity Assertion Authorization Grant (IETF draft)
• RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 8693: OAuth 2.0 Token Exchange
• OIDC Public Client Implementation Guide for the Flip identity provider endpoints

For questions or assistance, please contact your Customer Success representative.