Four flows that define agentic auth
When your security team asks whether your AI agent platform is "using proper OAuth" the honest answer is almost always: it depends on which OAuth. The OAuth specification universe has expanded significantly in the last few years, and the extensions that matter most for agentic workloads are precisely the ones enterprise identity providers were never designed to handle.
Azure Entra, Okta, AWS Cognito, and Auth0 are not bad. They were designed for a world of human users with browser sessions, where applications are pre-registered by administrators. That world still exists and matters. But agents are fundamentally different. Agents do not have browser sessions. They are programmatically spawned and terminated. They run for hours without any user interaction. They call other agents directly, negotiate capabilities at runtime, and need to authenticate to services that have never seen them before.
Before mapping IdP support, it helps to enumerate the four distinct flows an agentic system has to satisfy.
| Flow | Concrete example | What auth must do |
|---|---|---|
| Human → MCP client → MCP server | VS Code or Claude Desktop connecting to a private MCP server | Authorization code flow + PKCE + refresh token; client must auto-discover the auth server |
| Agent → Agent (A2A M2M) | An orchestrator agent calling a specialized analyst agent | Client credentials; no user in the loop; token scoped to agent identity |
| Agent → MCP server | An orchestrator calling a GitHub MCP tool on behalf of a workflow | Client credentials or OBO delegation; MCP client auto-discovers the auth server |
| Agent → External third party | An MCP server brokering calls to Slack, GitHub, or a payment API | Per-service credential storage, token lifecycle management, scoped egress |
The two human-adjacent flows — Human→MCP and Agent→Agent — are the ones enterprise IdPs handle worst. The human flow needs auto-discovery, which none of the major enterprise IdPs implement. The agent-to-agent flow exposes refresh-token policy, token-exchange, and dynamic-registration limitations that only become visible at the scale of a real deployment.
The six RFCs that actually matter
The OAuth ecosystem has dozens of extensions, but for agentic workloads six of them cause most of the friction. Knowing what each does for agents — and why it is needed — is the basis of any honest IdP evaluation.
- 01
RFC 7591 — Dynamic Client Registration
OAuth's traditional pattern requires an administrator to pre-register clients at the IdP before they can request tokens. That model breaks for agentic systems: agents are constantly being deployed; MCP clients (VS Code, Claude Desktop) frequently access resources they have never seen; agent runtimes can spawn hundreds of separate identities. RFC 7591 defines a standard POST /register endpoint where clients register themselves at runtime and receive a client_id (and optionally a client_secret). The MCP specification (2025-11-05) requires DCR support — without it on the auth server, MCP client registration fails.
- 02
RFC 9728 — OAuth Protected Resource Metadata
This is the spec enterprise IdPs miss most often, and it is the most critical for agent scenarios. RFC 9728 defines a well-known URL —
/.well-known/oauth-protected-resource— that a resource server (e.g. an MCP server) serves so clients can discover its authorization server. Without RFC 9728, every MCP client has to be configured manually with the auth server URL for every MCP server it connects to. For three servers, manageable. In a dynamic enterprise where servers are registered and deregistered as agents come online, impractical. The MCP spec requires RFC 9728. As of today, none of the major enterprise IdPs publish this metadata natively. - 03
RFC 7636 — PKCE (Proof Key for Code Exchange)
RFC 7636 defines PKCE, which prevents interception of the authorization code by binding the request to a cryptographic challenge only the legitimate client can satisfy. The MCP spec requires PKCE for all authorization code flows. This is the one RFC every major enterprise IdP supports well — typically defaulting to S256 for public clients. If your authorization code flow already uses PKCE with S256, this box is checked.
- 04
RFC 8628 — Device Authorization Grant
CLI agents, headless workflows, and CI/CD pipelines cannot open a browser to complete an authorization code flow. RFC 8628 defines the device grant: it displays a short code and a URL on the running device; the human authenticates in a browser on another device, and the CLI obtains the token automatically. Relevant whenever an agent needs a one-time human bootstrap and then runs unattended with refresh tokens or client credentials.
- 05
RFC 8693 — Token Exchange
RFC 8693 describes how to trade one token for another — including on-behalf-of, where an agent holds a user's token and trades it for a token representing the agent acting on the user's behalf. Critical for delegation architectures where an orchestrator holds user context and passes auditable, user-scoped tokens down to sub-agents and tools. The most complex of the six, and the least consistently supported.
- 06
Refresh-token lifecycle for long-running agents
Not strictly an RFC issue but a policy one. An agent running a multi-hour compliance check, document processing pipeline, or scheduled analysis cannot pause for human re-auth. It needs either long-lived refresh tokens or a way to silently re-authenticate with its client credentials. Azure Entra explicitly does not issue refresh tokens for client credentials flows — fine for short tasks, structurally problematic for long ones, where token lifetime and task lifetime become two different numbers.
How enterprise IdPs compare
Here is how the five identity providers most commonly deployed in enterprise environments compare against the six requirements above, based on each provider's own documentation.
| RFC / requirement | Azure Entra | Okta | AWS Cognito | Auth0 | Keycloak |
|---|---|---|---|---|---|
| RFC 7591 Dynamic Client Registration | ❌ Not supported | ⚠️ Supported — requires a privileged bootstrap token with okta.clients.register scope | ❌ No standard RFC 7591 endpoint | ⚠️ Via Management API — non-RFC 7591, requires management token | ✅ Full open endpoint, no bootstrap token required |
| RFC 9728 Protected Resource Metadata | ❌ | ❌ | ❌ | ❌ | ⚠️ Community extension — not standard |
| RFC 7636 PKCE | ✅ | ✅ | ✅ | ✅ | ✅ |
| RFC 8628 Device Code | ✅ | ✅ | ⚠️ Limited — not all user pool configurations | ✅ | ✅ |
| RFC 8693 Token Exchange | ⚠️ OBO supported but differs from RFC 8693 semantics | ⚠️ Supported with Okta-specific constraints | ❌ | ❌ | ✅ Full RFC 8693 |
| Refresh tokens for M2M (client credentials) | ❌ Explicitly not issued | ✅ Configurable per application | ⚠️ Configurable but limited duration | ✅ Configurable | ✅ Fully configurable |
The RFC 9728 row is unanimous. Not one major enterprise IdP supports Protected Resource Metadata natively. This is structural — it requires the IdP vendor to add an endpoint they have not yet built. It cannot be fixed with configuration.
DCR is constrained everywhere. Entra has no DCR endpoint at all — registrations are created via Microsoft Graph API by an administrator or a service principal. Okta's endpoint is RFC 7591 compliant but requires a privileged bootstrap token. Auth0 requires a Management API token. Only Keycloak supports truly open DCR.
Token exchange and M2M refresh policy hurts complex architectures. Entra explicitly does not issue refresh tokens for client credentials — a documented design choice that is fine for short-lived M2M but disruptive for long-running agentic workflows where re-authentication mid-task can be expensive or impossible.
What the gaps mean in production
Three concrete failure modes show up in real agentic deployments, all traceable to the gaps above.
- 01
Manual auth-server configuration for every MCP client
When a team deploys an MCP server into a new environment, the URL of its auth server has to be distributed manually to every MCP client that will connect. When that environment is promoted (staging → production), every client configuration has to be updated. RFC 9728 removes this entirely — the MCP server publishes its auth server URL itself. Without RFC 9728, this coordination tax never goes away.
- 02
Admin-ticket bottleneck for every new agent
A deployment pipeline that creates new specialized agents (e.g. one per customer environment) needs each new agent to have a client_id at the IdP before it can call anything. Without DCR, this is either a manual admin task or a Graph API call with elevated permissions. Ten agents is manageable. A hundred is a deployment-blocking bottleneck.
- 03
Mid-task authentication failures in long-running workflows
A three-hour compliance scan starts under a client-credentials token issued by Entra. The token expires at the one-hour mark. Entra issues no refresh token for this flow, so the agent has to re-request a token using its stored client_id and client_secret. When that silent re-auth fails, the worker surfaces a generic
HTTP 401 invalid_tokenagainst whichever resource it happened to call next. The agent treats it as a transient downstream error and retries on the same token. Every retry returns 401 because the token is still expired. The scan stalls between hour one and hour two, and the failure only becomes visible when the workflow's deadline passes. The repair window matters: by the time on-call notices, anywhere from forty minutes to an hour of work has accumulated against a credential the agent cannot refresh, and the rerun starts from the last checkpoint, not from where the token died.
The authentication experience layer
The authentication experience layer (AEL) is a federation layer that sits in front of your existing IdP and adds the agentic-auth surface your IdP does not natively provide. It is not a replacement for Entra, Okta, or Cognito. It does not manage human identity. It bridges the gap between the identity infrastructure your organization already operates and the OAuth contract that agentic workloads require.
- 01
RFC 9728 compliance for every registered agent and MCP server
The layer serves
/.well-known/oauth-protected-resourcefor every endpoint in the agent registry, so MCP clients can auto-discover the authentication configuration for any authorized agent without manual URL distribution. - 02
RFC 7591 DCR — natively or by proxy
For IdPs that natively support DCR (Okta, Keycloak), the layer proxies the registration request and manages the privileged bootstrap token internally. For IdPs that do not (Entra), the layer maintains its own client registry and uses the IdP for identity federation only. Either way, agents self-register without an admin ticket.
- 03
PKCE enforcement regardless of IdP policy
The layer requires PKCE S256 for all authorization code flows, in addition to whatever the underlying IdP enforces, so the MCP security baseline holds even when the IdP would not require it.
- 04
Token lifecycle management for long-running agents
The layer manages refresh and silent re-authentication policy for agent workflows, transparently refreshing tokens for agents whose token is about to expire — so the long-running agent does not have to handle refresh itself.
- 05
Egress token brokering for external integrations
When an agent calls Slack, GitHub, or a payment API, the layer holds the raw third-party credential and hands the agent a short-lived, scope-narrowed egress token instead. The agent never sees the underlying secret, and the credential-exposure surface contracts to one point of control.
On the human side, users continue to authenticate to Entra, Okta, or Cognito exactly as they do today. The AEL layers the non-human-identity surface on top of the human-identity foundation through federation. No user migration. No second human identity store. No parallel directory.
Integrating with AgentCore and Foundry
Two platform integrations illustrate how the AEL changes the operational picture in practice.
Five questions for evaluating an AEL
Whether you are building one, deploying an open-source implementation, or evaluating a vendor, five questions tell you whether the layer actually closes the gaps — or just renames an OAuth proxy.
- 01
Does it serve RFC 9728 Protected Resource Metadata for every registered agent and MCP server?
This is the clearest differentiator between a genuine AEL and an OAuth proxy that happens to sit in front of your IdP. Without per-endpoint PRM, MCP clients still need manual auth-server configuration — and the discovery problem is unsolved.
- 02
Does it implement RFC 7591 DCR — natively or by proxy — so agents self-register without an admin ticket?
The practical test: can a new agent deployed in your pipeline obtain a client_id and begin authenticating within the same deployment run, with no manual step? If not, DCR isn't actually solving the provisioning problem.
- 03
Does it decouple token lifetime from task duration for long-running workflows?
An AEL that issues short-lived tokens without a refresh policy is not solving the long-running-agent problem — it is moving the failure from the IdP to the layer. The lifecycle has to be the layer's responsibility, not the agent's.
- 04
Does it federate with your existing enterprise IdP rather than requiring a parallel human-identity migration?
Any implementation that requires migrating users out of Entra or Okta is a replacement IdP, not an experience layer. Federation is the architectural test — and a failing answer here is a deal-breaker for most enterprises.
- 05
Does it propagate registration and auth metadata to the agent registry and gateway so policy enforcement shares one source of truth?
In a well-governed platform, the registry knows which agents exist, the gateway enforces which agents can communicate, and the AEL controls which agents can authenticate. When those three derive state from the same registration event, policy is enforced consistently. When they are independent systems, configuration drift between them becomes the primary governance risk.
How the Jarvis authentication layer implements this
These are the gaps that shaped how we designed the authentication layer of Jarvis AI. The Jarvis authentication experience layer is open source and built around the five questions above.
It serves /.well-known/oauth-protected-resource for every agent and MCP server registered in Jarvis Registry. It implements RFC 7591 DCR with PKCE always required, so VS Code, Claude Desktop, and Claude Code CLI connect to any Jarvis-registered MCP server without manual credential distribution. It federates with Entra, Okta, and AWS Cognito, so the human-identity infrastructure stays where it is. And it integrates natively with Jarvis Registry and the Jarvis MCP Gateway, so agent registration, auth configuration, and gateway policy all derive from the same source of truth.
References
Primary sources behind the claims in this article.
| Source | URL |
|---|---|
| RFC 7591 — OAuth 2.0 Dynamic Client Registration Protocol | rfc-editor.org/rfc/rfc7591 |
| RFC 9728 — OAuth 2.0 Protected Resource Metadata | rfc-editor.org/rfc/rfc9728 |
| RFC 7636 — Proof Key for Code Exchange (PKCE) | rfc-editor.org/rfc/rfc7636 |
| RFC 8628 — OAuth 2.0 Device Authorization Grant | rfc-editor.org/rfc/rfc8628 |
| RFC 8693 — OAuth 2.0 Token Exchange | rfc-editor.org/rfc/rfc8693 |
| RFC 7662 — OAuth 2.0 Token Introspection | rfc-editor.org/rfc/rfc7662 |
| MCP Authorization Specification (2025-11-05) | spec.modelcontextprotocol.io/specification/2025-11-05/basic/authorization/ |
| Microsoft Entra — OAuth 2.0 Client Credentials Flow | learn.microsoft.com/.../v2-oauth2-client-creds-grant-flow |
| Okta — Dynamic Client Registration API | developer.okta.com/docs/api/openapi/okta-oauth/oauth/client |
| AWS AgentCore — Custom JWT Authorizer | docs.aws.amazon.com/.../agentcore-auth.html |
| Azure AI Foundry Agent Service — Authentication | learn.microsoft.com/.../ai-foundry/agents/overview |
| Jarvis Agent Registry | exploreagentic.ai/agent-registry/ |
| Jarvis Agent Gateway | exploreagentic.ai/agent-gateway/ |
| Agent Registry vs. Agent Gateway | exploreagentic.ai/agent-gateway/agent-registry-vs-agent-gateway/ |
| Jarvis Registry — Open Source Agent Registry | jarvisregistry.com |
Closing
Enterprise IdPs are built for human identity at enterprise scale, and they do that job well. The RFC gaps documented here are not failures — they are design boundaries reflecting the workloads those platforms were built to serve. Dynamic registration, protected resource discovery, long-lived M2M token management, on-behalf-of delegation: none of these were central use cases when Entra, Okta, or Cognito were architected.
The authentication experience layer is what closes the distance between the identity infrastructure your organization already operates and the authentication contract that agentic workloads actually require. It adds the non-human-identity surface without displacing the human-identity foundation. It implements the missing RFCs without forcing migration away from the IdP your security team already knows how to govern.
The agents are already deploying. The question is whether the authentication infrastructure around them was designed for them.
Common questions
-
Does an authentication experience layer replace my IdP?
No. The AEL federates with your existing IdP for human identity. Users continue to authenticate to Entra, Okta, or Cognito as they do today. The AEL only adds the non-human-identity surface — DCR, Protected Resource Metadata, M2M token lifecycle, egress brokering — that the IdP does not natively provide. -
Why is RFC 9728 (Protected Resource Metadata) so important for MCP?
RFC 9728 defines the well-known endpoint MCP clients use to discover an authorization server for a resource. Without it, every MCP client has to be configured manually with the auth server URL for every server it connects to. The MCP spec requires it. None of the major enterprise IdPs implement it natively. An AEL serves it on the IdP's behalf for every registered agent and MCP server. -
Can I use Dynamic Client Registration with Azure Entra?
Entra has no RFC 7591 DCR endpoint. Client registrations are created through the Microsoft Graph API by an administrator or a service principal with sufficient permissions. An AEL closes this gap by maintaining its own client registry for agents while federating identity back to Entra — agents self-register at the layer instead of at Entra. -
What about long-running agent workflows whose tokens expire mid-task?
An AEL takes ownership of token lifecycle so the agent does not have to. The layer refreshes or re-issues tokens transparently before expiry, even for IdPs like Entra that do not issue refresh tokens for client credentials. The token lifetime is decoupled from the task duration — which is the only way mid-task auth failures stop being a production incident.