Why agentic auth is a distinct problem
A human user signs in once and gets a session. An AI agent operates very differently:- It acts on behalf of a user, but is not the user.
- It may be one of thousands of agent instances, each needing its own credential.
- It calls tools (MCP servers) the user never directly touches.
- Tokens it holds must be scoped to specific resources so a token stolen from one tool can’t be replayed against another.
The layers of agentic auth
When an agent calls an MCP server, three concerns must be addressed:- User identity. Who is the human ultimately authorizing this action? (SSO, SAML, OIDC.)
- Agent identity & delegation. Which agent instance is calling? On whose behalf? With which scopes, for how long?
- Resource binding. Is the token presented at this MCP server actually scoped to this server, not to some other one the agent also has access to?
Implementation patterns
Most teams end up on one of five stacks. Each is defensible; each makes different tradeoffs.Pattern A — Roll your own
You operate your own OAuth 2.1 authorization server and host your MCP server on whatever compute you already use.- Exemplars: Self-built on top of libraries like
oauth4webapiornode-oidc-provider. - What you own: Token issuance, JWKS rotation, PKCE enforcement, resource binding, protected resource metadata endpoints, audit logging.
Pattern B — Managed identity + DIY MCP layer
You use a managed enterprise IdP for user/agent identity, then build the MCP-specific auth surface (resource metadata, audience checks, token validation) yourself.- Exemplars: WorkOS, Auth0/Okta, Stytch (now part of Twilio) for the identity layer.
- What the IdP owns: SSO, SCIM, OIDC, refresh-token flows, account recovery.
- What you own: Everything MCP-spec-specific from layer 3 above.
Pattern C — Agent-action gateway
A platform sits between your agent and the external APIs it calls, brokering OAuth on the agent’s behalf to each upstream service.- Exemplars: Composio, Nango, Arcade.
- Best fit: Agents that need to act across dozens of third-party APIs (Gmail, Slack, GitHub, etc.) where managing each OAuth dance individually is the dominant cost.
- Note: This is auth for outbound agent → SaaS API calls. It does not host the MCP servers your own agents expose.
Pattern D — Platform-runtime auth
A serverless compute platform with a first-party agent runtime where auth is wired into the runtime primitives.- Exemplars: Cloudflare Workers + Agents SDK (with Cloudflare Access or an external IdP).
- Best fit: Teams already on the platform who want MCP execution and auth co-located with the rest of their edge workload.
- What you still own: Wiring the OAuth 2.1 authorization server (BYO), resource metadata, and MCP-spec specifics.
Pattern E — Managed MCP hosting with bundled auth
A purpose-built MCP hosting layer that ships an OAuth 2.1 authorization server, PKCE, RFC 8707 resource binding, and RFC 9728 protected resource metadata as defaults — and accepts BYO identity providers for teams that already have one.- Exemplar: ezForge.
- Best fit: Teams who want MCP-spec compliance out of the box and the option to plug in their existing IdP later.
Tradeoffs from a customer perspective
The patterns are not exclusive. A common production topology is C for outbound + B or E for inbound — agent-action gateways for the agent’s outgoing calls, managed MCP hosting for the agent’s own exposed servers.
Where ezForge fits
ezForge is Pattern E: managed MCP hosting with a first-party, spec-compliant OAuth 2.1 authorization server bundled in. Two entry paths:- Managed mode —
app.ezforge.aiissues tokens; PKCE, RFC 8707, and RFC 9728 are default-on; you point your agent at the server URL and start calling tools. - BYOA mode — Bring your existing OAuth 2.1 issuer (WorkOS, Auth0, Stytch/Twilio, or any compliant provider) and ezForge forwards tokens to your MCP server for validation against it.