How AI agents authenticate to MCP servers

Same auth as your humans. Now extended to AI.

Hoop's MCP OAuth configuration adds OAuth 2.1 Resource Server support to the MCP endpoint, following the official Model Context Protocol 2025-11-25 authorization profile. Your existing identity provider can now authenticate AI agents the same way it authenticates humans, with short-lived JWTs replacing persistent bearer tokens.

Why it matters

An engineer leaves the company on a Friday. By Friday afternoon, IT has deactivated their Okta account, their VPN access, their email, their GitHub. The standard offboarding checklist gets run.

Then on Monday, their Claude Code configuration is still on a colleague's laptop because the project moved over. The agent is set up with a bearer token issued months ago. That token is still valid. The agent can still hit production.

The bearer token does not know the human is gone. It is a long-lived secret tied to the person only by convention, not by mechanism. Most teams have not added "revoke AI agent tokens" to their offboarding checklist yet.

The fix is not a new tool for AI offboarding. The fix is to make AI agents authenticate the same way humans do: through your IdP, with tokens that die when the human dies.

How do AI agents authenticate to MCP servers?

Most MCP deployments today handle authentication one of three ways:

Approach	Identity lifecycle	Per-agent provisioning	IdP integration
Static bearer tokens	None — token outlives the human	Manual, gets stale	None
Scoped API keys	None	Manual, per-agent	None
Custom OIDC bridges	Yes, but brittle	Per-IdP rewrite	Heavy maintenance
hoop MCP OAuth 2.1	Tied to IdP session	Inherited from human user	Standards-based, any OAuth 2.1 IdP

The hoop.dev approach is different in one specific way: standards-based federation. Your IdP authenticates the human. The user's session issues a short-lived JWT. The agent calls hoop with that JWT. When the JWT expires, the agent re-authenticates through your IdP. When the human's account is deactivated, all future JWTs fail.

No new identity layer for AI agents. No separate provisioning workflow. No custom bridge to maintain. The same IdP that already governs your humans now governs your agents — and the same lifecycle controls apply to both.

What is the MCP 2025-11-25 specification?

The MCP 2025-11-25 authorization profile is the official spec for how MCP servers and clients handle authentication. It defines the OAuth 2.1 flow, the metadata discovery, the token format. Hoop implements that spec natively.

Continue reading? Get the full guide.

AI Agent Security + SSH Bastion Hosts / Jump Servers: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Why does that matter? Three reasons:

First, any MCP client that follows the spec works with Hoop without custom integration. New clients ship all the time. Anything that respects the authorization profile authenticates against Hoop's endpoint correctly out of the box.

Second, your IdP needs no custom Hoop integration. Hoop reads standard OAuth 2.1 metadata. If your IdP can do OAuth 2.1, your IdP can do Hoop.

Third, the spec gives you a moving target worth tracking. As the MCP ecosystem matures, the authorization profile will evolve. Hoop tracks the spec. You inherit the improvements.

What changes for you

Three shifts the day you turn this on:

Your offboarding process now covers AI agents automatically. Deactivate the user in your IdP, every agent that was authenticated as that user loses access on next token refresh. No separate AI-agent offboarding step.

Bearer tokens become a liability you can retire. Long-lived secrets stored on developer laptops were always the weakest link in your AI access posture. With OAuth 2.1, you can phase them out once your team has migrated.

Your IdP becomes the single control plane for human and agent access. The same MFA, the same conditional access policies, the same session timeouts that govern your humans now govern your AI agents. One identity layer, not two.

What this pairs with

Yesterday we shipped the user MCP server: eight tools that let AI coding agents act with the identity of the human user they are working for. Today's launch ties that identity to your existing IdP through OAuth 2.1.

The two together close the loop. Your IdP authenticates the human. The human's session issues a JWT that scopes the AI agent's access. Every call the agent makes through MCP runs through your policy engine, your audit log, and your approval workflows, attributed to the human user.

The bigger picture

Two weeks ago we shipped the admin MCP server: AI agents managing Hoop itself. Yesterday, the user MCP server: AI agents acting on infrastructure as their human user. Today, OAuth 2.1: that identity tied to your existing IdP.

Same architecture every time. AI agents do not get a governance exemption. They work inside the rules everyone else does.

Definitions

Bearer token A token that grants access to whoever holds it ("bearer"), with no additional verification of identity. Long-lived bearer tokens are the default for most MCP deployments today and the primary security weakness this post addresses.
MCP (Model Context Protocol) is the standard way AI agents discover and call external tools, introduced by Anthropic in 2024.
hoop.dev is an access gateway that sits between engineers, AI agents, and production infrastructure. Every action runs through Hoop's policy engine, data masking, approval workflows, and audit trail.
OAuth 2.1 is the current version of the OAuth authorization framework. It consolidates the security best practices accumulated under OAuth 2.0.
OAuth 2.1 Resource Server. An OAuth role for a service that hosts protected resources and validates access tokens issued by an authorization server. Under the MCP 2025-11-25 specification, MCP servers are classified as OAuth Resource Servers.
OIDC (OpenID Connect) is the identity layer built on top of OAuth 2.0/2.1, used by most modern IdPs to issue identity tokens.
RFC 9728 specifies how OAuth 2.0 Protected Resource servers expose their auth metadata, so clients can discover where to authenticate.
MCP 2025-11-25 authorization profile is the official spec for OAuth 2.1 authentication of MCP servers and clients, published by the Model Context Protocol project.
JWT (JSON Web Token) is the token format that OAuth 2.1 / OIDC IdPs typically issue. Short-lived, signed, contains identity and group claims.
Identity federation for AI agents means the agent inherits the permissions of the human user who started the session, rather than getting its own credentials.
Group claim normalization is the process of mapping how different IdPs emit group memberships in their tokens to a single internal group model. Different IdPs use different claim names and structures; normalization makes them all look the same downstream.