How should an MCP server authenticate users and AI agents?
Updated · DBShifts
Short answer
Use OAuth, not long-lived keys pasted into a client's config. The MCP specification authorizes remote servers with OAuth 2.1: the person signs in from their MCP client, the client gets a short-lived token through PKCE, and the server checks who the person is on every request — so access follows the person and revoking it is immediate.
Key facts
- The MCP authorization specification uses OAuth 2.1 for remote servers.
- PKCE lets an MCP client with no client secret, such as a desktop app or editor, complete OAuth safely.
- Dynamic client registration lets a new MCP client register itself without manual setup.
- A token should be bound to one server, so a token issued for one MCP server cannot be replayed at another.
- Group membership from your identity provider should be re-checked on each request, not only at sign-in.
In the glossary:OAuth for MCP
Why static keys fail
A key in mcp.json is usually shared by a team, copied between laptops, committed by accident and never rotated. Every request it makes looks the same, so you cannot tell which person did what, and removing one person means changing the key for everyone.
How OAuth works for MCP
The client calls the server, receives a pointer to its authorization server, registers itself if it has not before, and opens a browser for the person to sign in. It exchanges the returned code — proven with PKCE — for an access token and a refresh token, and sends the access token with every MCP request. When the access token expires, the refresh token gets a new one; rotating refresh tokens means a stolen one stops working after its first use.
What to bind, and what to re-check
Bind each token to the one server it was issued for. Decide access from the person's own grant or their identity-provider group, and re-check that on every request, so someone removed from a group loses access immediately rather than when their token expires.
Checklist
- 1
OAuth 2.1 for every remote MCP server
- 2
PKCE with S256 for public clients
- 3
Tokens bound to a single server
- 4
Short-lived access tokens with rotating refresh tokens
- 5
Access re-checked against groups on every request
- 6
A way to sign one person out of every client
Common mistakes
One API key for the whole team
Nothing in the log says who made a request, and revoking one person breaks everyone else's setup.
Checking permissions only at sign-in
A person who changes role keeps their old access for as long as their token lives. Re-check on each request.
How DBShifts does it
- DBShifts Agent Gateway supports per-person sign-in from MCP clients with OAuth 2.1: authorization code with PKCE (S256), dynamic client registration and rotating refresh tokens.
- Each token is bound to one gateway, and what a person may read comes from their own grant or their identity-provider group, re-checked on every request.
- The AI Data Front Door gives every AI app one sign-in URL over several gateways and document libraries, and can require an owner to approve each app before it connects.
Questions people also ask
What about agents that run with no person, like background jobs?
Give each its own scoped token, bound to one server and revocable on its own, and log it as that agent. Never reuse a person's token for an unattended job.
Does every MCP client support OAuth sign-in?
Support has spread quickly but is not universal. For a client that cannot sign in, issue a per-agent scoped token rather than a shared key.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free28 answers in this series. See all or browse the AI agent glossary.