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
| If you are… | The pattern that usually fits | Why |
|---|---|---|
| An indie developer launching a single MCP server | E, with an option to drop down to A later | Lowest time-to-first-call; spec-compliant by default |
| A B2B SaaS with existing SSO/SCIM customers | B or E with BYOA | Reuses your enterprise identity contract; MCP layer is the only new surface |
| Building an agent that wraps many third-party SaaS APIs | C for outbound + E for the agent’s own exposed MCP surface | The two concerns are orthogonal; use the best tool for each |
| Already running serverless workloads at scale on a single platform | D | Co-location lowers operational variance |
| An enterprise with strict residency/isolation requirements | A or E in BYOA self-host mode | Full data-path control with the option of a managed control plane |
| Onboarding non-technical SMB customers | E in a turnkey configuration | No OAuth configuration exposed to the customer |
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 —
auth.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 validates tokens against it.