Aembit’s Model Context Protocol: A standard protocol for AI agent and server interactions that defines how AI assistants communicate with external tools and data sources.Learn more(opens in new tab) Authorization Server secures MCP workloads using OAuth 2.1 authorization flows. It implements the authorization functionality defined in the MCP specification. AI agents and MCP clients authenticate and receive access tokens governed by Aembit Access 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.
What it does
Section titled “What it does”- Handles OAuth for MCP - Implements the OAuth 2.1 authorization code flow from the MCP specification so you don’t have to build it yourself
- Works with existing MCP clients - Supports 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, so tools like Gemini CLI and Claude Desktop can connect without pre-configuration
- Uses your existing identity provider - Integrates with OIDC and SAML providers (Okta, Azure AD, Google) for user authentication
- Adds access control - Apply Aembit Access 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 restrict who can access which MCP servers, with optional time and location conditions
- Runs in Aembit Cloud - Available in v1.27+ with no additional agents to deploy
When to use it
Section titled “When to use it”Use Aembit’s MCP Authorization Server when you need to:
- Secure MCP-compliant workloads or AI agents using OAuth 2.1 flows
- Apply fine-grained access control, including geo/time-based conditions and integration with OIDC identity providers
- Enable dynamic client registration and seamless integration with MCP clients like Claude Desktop and Gemini CLI, or use MCP Jam for testing and debugging your authorization flows
How it works
Section titled “How it works”Aembit’s MCP Authorization Server processes requests through these steps:
- Client registration - MCP clients register with the MCP Authorization Server using a redirect URI as their identifier, via dynamic client registration
- Authorization request - Clients initiate OAuth 2.1 flows, redirecting users for authentication through their configured identity provider
- Policy evaluation - Aembit evaluates Access Policies, including trust provider attestation and access conditions
- Token issuance - On successful authorization, the server issues access tokens for use with MCP servers using the OIDC ID Token Credential Provider
- Token validation - MCP servers validate tokens using standard OIDC/JWKS: JSON Web Key Set - A set of cryptographic keys published at a well-known endpoint, used to verify the signatures of JSON Web Tokens (JWTs) issued by an authorization server.Learn more mechanisms. Aembit lets you configure the audience, issuer, subject claims, and token lifetime
For an architecture diagram showing these components, see MCP Authorization Server architecture.
Current authentication support
Section titled “Current authentication support”Aembit’s MCP Authorization Server supports human/user authentication through OIDC and SAML Identity Providers. Users authenticate through their browser using their identity provider (IdP) such as Azure AD, Okta, or Google.
| Authentication type | Description | Supported? |
|---|---|---|
| Human/user | Users authenticate via OIDC or SAML Identity Providers (Azure AD, Okta, Google) | ✅ |
| Non-human workload | Service accounts, AWS IAM roles, Azure Managed Identity | ❌ |
Choosing between OIDC and SAML
Section titled “Choosing between OIDC and SAML”Aembit’s MCP Authorization Server supports both OIDC and SAML identity providers. Both require a Credential Provider to generate access tokens, but they differ in Trust Provider support:
| Protocol | Trust Provider | Credential Provider |
|---|---|---|
| OIDC | OIDC ID Token Trust Provider | Required |
| SAML | Not available | Required |
- OIDC: Use the OIDC ID Token Trust Provider in your Access Policy to validate identity tokens. A Credential Provider generates the access token.
- SAML: A Credential Provider generates the access token. Trust Provider validation isn’t available for SAML identity providers (a SAML Trust Provider doesn’t exist yet).
Both protocols require an identity provider configured in your Aembit tenant under Administration > Identity Providers.
If you configure multiple identity providers for your tenant, users select their IdP during the authentication flow.
In this section
Section titled “In this section”- MCP Authorization Server concepts - URL configuration, token handling, and Access Policy components
- Set up the MCP Authorization Server - Configure Access Policies and deploy the service
- MCP Authorization Server reference - Configuration options, endpoints, and error codes
- Troubleshoot the MCP Authorization Server - Common errors and solutions