MCP Authorization Server concepts

This page covers the key concepts you need to understand when working with the Aembit Model Context Protocol (MCP) Authorization Server. For setup instructions, see Set up the MCP Authorization Server.

Access control

Aembit’s MCP Authorization Server uses Aembit Access PoliciesAccess Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more to control access. An Access Policy connects these components to answer key questions during authorization:

• Client WorkloadClient Workload: Client Workloads represent software applications, scripts, or automated processes that initiate access requests to Server Workloads, operating autonomously without direct user interaction.Learn more - Identifies which MCP client is requesting access. For MCP, the redirect URI from Dynamic Client Registration serves as the client identifier. This enables granular policies per client application (such as Gemini CLI or MCP Jam).

• Server WorkloadServer Workload: Server Workloads represent target services, APIs, databases, or applications that receive and respond to access requests from Client Workloads.Learn more - Identifies which MCP server the client wants to access. The Server Workload configuration (host, port, path) must align with your MCP server’s URL and the resource parameter. See URL configuration alignment for details.

• Trust ProviderTrust Provider: Trust Providers validate Client Workload identities through workload attestation, verifying identity claims from the workload's runtime environment rather than relying on pre-shared secrets.Learn more - Validates user identity during the authorization flow. For MCP with human authentication, the OIDC ID Token Trust Provider matches claims (issuer, audience, subject) from your identity provider to verify the user. When Enforce SSO is off on the Client Workload, no Trust Provider is needed.

• Access ConditionsAccess Condition: Access Conditions add dynamic, context-aware constraints to authorization by evaluating circumstances like time, location, or security posture to determine whether to grant access.Learn more - Adds context-based restrictions such as time-of-day or geolocation. For geolocation conditions, both the MCP client’s IP and the user’s browser IP must satisfy the restriction.

• Credential ProviderCredential Provider: Credential Providers obtain the specific access credentials—such as API keys, OAuth tokens, or temporary cloud credentials—that Client Workloads need to authenticate to Server Workloads.Learn more - Generates the access token that the MCP client uses to authenticate with the MCP server. The token includes an audience claim matching the Server Workload and uses the configured signing algorithm (ES256 (default) or RSA).

For step-by-step configuration, see Set up the MCP Authorization Server.

MCP Authorization Server architecture

This diagram shows how Aembit’s MCP Authorization Server fits into the MCP ecosystem. Aembit sits between MCP clients and MCP servers, applying Access Policy controls to authorization flows.

The authorization flow differs depending on your configuration. When Enforce SSO is on for your Client Workload (the default), users authenticate through your identity provider. Select your protocol to see the flow. When Enforce SSO is off, the flow skips user authentication entirely.

OIDC

SAML

No user auth

How OIDC authorization works

1. Initiate command - The user runs a command in their MCP client (like Gemini CLI)
2. Register and request auth - The MCP client registers with Aembit and requests authorization
3. Redirect to IdP - Aembit redirects the user’s browser to the OIDC identity provider
4. Authenticate - The user signs in with their corporate credentials
5. Return ID token - The identity provider returns an OIDC ID token to Aembit’s Trust Provider
6. Verify - The Trust Provider validates the ID token claims (issuer, audience, subject)
7. Check - Access Conditions check contextual factors (time, location)
8. Issue access token - The Credential Provider generates a JWT access token
9. Access with bearer token - The MCP client uses the token to access the protected MCP server

How SAML authorization works

1. Initiate command - The user runs a command in their MCP client (like Gemini CLI)
2. Register and request auth - The MCP client registers with Aembit and requests authorization
3. Redirect to IdP - Aembit redirects the user’s browser to the SAML identity provider
4. Authenticate - The user signs in with their corporate credentials
5. Return SAML assertion - The identity provider returns a SAML assertion to Aembit’s Trust Provider
6. Verify - The SAMLv2 Response Trust Provider validates the SAML assertion
7. Check - Access Conditions check contextual factors (time, location)
8. Issue access token - The Credential Provider generates a JWT access token
9. Access with bearer token - The MCP client uses the token to access the protected MCP server

How no-user-auth authorization works

1. Initiate command - The user runs a command in their MCP client (like Gemini CLI)
2. Register and request auth - The MCP client registers with Aembit and requests authorization
3. Check - Access Conditions check contextual factors (time, location) using the MCP client’s IP address
4. Issue access token - The Credential Provider generates a JWT access token
5. Access with bearer token - The MCP client uses the token to access the protected MCP server

No user authentication or Trust Provider

When Enforce SSO is off on the Client Workload, the MCP Authorization Server skips user authentication entirely. There is no browser redirect, no identity provider interaction, and no Trust Provider validation. The Credential Provider still generates the access token, and Access Conditions still apply.

For guidance on choosing between OIDC and SAML, see MCP Authorization Server overview.

Client authentication

Aembit’s MCP Authorization Server supports Dynamic Client Registration (DCR)Dynamic Client Registration: An OAuth mechanism that allows MCP clients to register with the Authorization Server at runtime without pre-configuration, receiving unique credentials for subsequent authorization requests.Learn more for MCP client registration. This section covers how clients register and how redirect URIs identify them.

Client registration

With Dynamic Client Registration (DCR), MCP clients register themselves at runtime by sending a registration request to the /register endpoint. The Authorization Server returns a unique client_id for subsequent authorization requests.

For detailed DCR mechanics, see the MCP authorization specification.

Client ID in Metadata Discovery (CIMD) support

Aembit’s MCP Authorization Server supports DCR only. Client ID in Metadata Discovery (CIMD), which provides a shared client_id in OAuth metadata, isn’t supported.

Redirect URIs

In OAuth 2.1, a redirect URI is the callback URL where the Authorization Server sends users after they authenticate. When an MCP client registers through Dynamic Client Registration, it provides its redirect URI, which tells the Authorization Server where to send the authorization code after successful authentication.

For details on the OAuth 2.1 redirect flow, see RFC 6749.

Redirect URIs as Client Workload identifiers

In Aembit Access Policies, the redirect URI serves a dual purpose. It’s both the OAuth callback URL and the identifier for your Client Workload. This enables granular access policies based on which MCP clients are requesting access. For step-by-step configuration, see Redirect URI identifier.

For example, if Gemini CLI registers with http://localhost:7777/oauth/callback, you would configure a Client Workload with the Redirect URI identifier type set to this value. This ensures only authorized MCP clients can obtain access tokens for your protected MCP servers.

Common redirect URI patterns

Different MCP clients use different redirect URI formats depending on whether they run locally or remotely.

Local development:

MCP client	Redirect URI
MCP Jam	http://localhost:6274/oauth/callback
Gemini CLI	http://localhost:7777/oauth/callback

Remote or cloud-hosted:

MCP client	Redirect URI
Claude Desktop	https://claude.ai/api/mcp/auth_callback
Custom web app	https://your-app.example.com/oauth/callback

Port numbers for loopback URIs

For loopback IP addresses (localhost and 127.0.0.1), Aembit ignores the port number during redirect URI matching. This means a Client Workload configured with http://localhost:7777/oauth/callback will match requests from any port like http://localhost:8080/oauth/callback or http://localhost:3000/oauth/callback. Wildcards aren’t supported in redirect URIs.

Token handling

This section covers token issuance, validation, and refresh behavior in the MCP authorization flow.

Token audience

The audience claim is a standard JWT claim that identifies the intended recipient of a token - in this case, your MCP server.

In Aembit, you configure the audience value in your Credential Provider settings. This value must match exactly what your MCP server expects in its token verifier configuration. For example, https://mcp.acme-corp.example.com and https://mcp.acme-corp.example.com/ (with trailing slash) are different values and cause validation to fail.

Credential acquisition

Aembit’s MCP Authorization Server supports acquiring credentials for downstream services through Aembit’s Credential Provider system.

Supported credential types

When an MCP client successfully authenticates, the Authorization Server provides OIDC ID Tokens (JWT tokens) for accessing protected MCP servers.

Configure the credential type in your Access Policy’s Credential Provider settings. See Credential Providers for available options.

URL configuration alignment

Three URLs must align for the MCP authorization flow to succeed:

Component	Configuration	Example value
MCP Client	Target URL	https://mcp.acme-corp.example.com/mcp
MCP Server	resource	https://mcp.acme-corp.example.com
Aembit	Server Workload (host, port, path)	mcp.acme-corp.example.com:443/mcp

The resource parameter omits the path (/mcp) because it identifies the server origin for token audience matching, not the specific endpoint. The MCP client and Aembit Server Workload include the full path to specify the MCP endpoint mount location. If these URLs don’t match, you encounter URL mismatch errors.

Why alignment matters

During the OAuth flow:

1. The MCP client connects to your MCP server using its target URL
2. The MCP client receives protected resource metadata (including the resource parameter) from your MCP server
3. Aembit verifies the resource parameter matches the Server Workload configuration in the Access Policy
4. The MCP client requests a token from the Aembit MCP Authorization Server
5. The Aembit MCP Authorization Server validates the request against your Server Workload configuration

A mismatch at any step causes the authorization flow to fail.

Related resources

• MCP Authorization Server overview
• Set up the MCP Authorization Server
• MCP Authorization Server reference
• Troubleshooting