OAuth Bearer Tokens for MCP: Complete Guide
Modern Model Context Protocol (MCP) servers frequently connect AI applications to cloud services, enterprise platforms, internal APIs, and business systems.
Before a client can access these protected resources, it must prove that it is authorized to do so.
This is where OAuth Bearer Tokens come in.
After a successful OAuth authentication flow, the Authorization Server issues an Access Token. The MCP client then includes this token with every request to the remote MCP server, allowing the server to verify the client's identity and permissions.
In this guide, you'll learn how Bearer Tokens work in MCP, how they're validated, why they should only be transmitted in HTTP headers, and the security best practices recommended for modern OAuth deployments.
Quick Answer
OAuth-enabled MCP servers use Bearer Access Tokens to authenticate requests. Clients send the token in the HTTP
Authorizationheader using the formatBearer <access-token>. The MCP server validates the token before executing any requested operation.httpAuthorization: Bearer eyJhbGciOi...
What Is a Bearer Token?
A Bearer Token is an OAuth Access Token.
It represents authorization that has already been granted by the user through an Authorization Server.
Instead of asking the user to log in before every request, the client simply presents the access token.
A simplified authentication flow looks like this:
User
│
Authenticate
│
▼
Authorization Server
│
Issues Access Token
│
▼
OAuth Client
Once the client has obtained the token, it can communicate with the remote MCP server until the token expires.
Why MCP Uses Bearer Tokens
Remote MCP servers often expose sensitive resources such as:
- source code repositories
- documentation platforms
- cloud infrastructure
- databases
- internal APIs
- business applications
Requiring users to authenticate before every request would create a poor user experience.
Bearer Tokens solve this by allowing clients to authenticate once and securely reuse the issued access token for subsequent requests.
This approach combines security with efficiency.
How Bearer Tokens Are Used
Every request to an OAuth-protected MCP server includes the access token inside the HTTP Authorization header.
The overall process looks like this:
User
│
▼
OAuth Authorization
│
▼
Authorization Server
│
▼
Access Token
│
▼
Cursor / Claude Code
│
Authorization: Bearer xxxxxxxxx
│
▼
Remote MCP Server
│
Validate Token
│
▼
Execute Tool
The client never needs to resend the user's credentials after authentication has completed.
Instead, the Bearer Token acts as temporary proof of authorization.
The Authorization Header
OAuth Bearer Tokens should be transmitted using the standard HTTP Authorization header.
A request typically looks like this:
Authorization: Bearer eyJhbGciOi...
This approach keeps authentication separate from URLs and request payloads.
Modern OAuth specifications—and the MCP authorization specification—recommend using the Authorization header rather than transmitting tokens through query parameters or other less secure mechanisms.
Why Tokens Should Never Be Sent in URLs
Including access tokens in query parameters creates unnecessary security risks.
URLs may be:
- stored in browser history
- written to server logs
- captured by monitoring systems
- leaked through referrer headers
- shared accidentally
Using the Authorization header prevents many of these problems because headers are handled separately from URLs.
For this reason, modern OAuth implementations treat Authorization headers as the standard mechanism for transmitting Bearer Tokens.
How MCP Servers Validate Bearer Tokens
Receiving a Bearer Token is only the beginning.
Before an MCP server executes any tool or exposes any resource, it must determine whether the token is valid.
A typical validation process includes several checks:
- Is the token authentic?
- Has it expired?
- Was it issued by the expected Authorization Server?
- Is it intended for this MCP server?
- Does it contain sufficient permissions?
Only after these checks succeed should the server process the request.
A simplified validation flow looks like this:
Incoming Request
│
▼
Read Authorization Header
│
▼
Validate Access Token
│
├── Signature
├── Expiration
├── Issuer
├── Audience
└── Permissions
│
▼
Execute Tool
If any validation step fails, the request should be rejected.
Token Expiration
Unlike API keys, OAuth Access Tokens are intentionally short-lived.
Limiting their lifetime reduces the impact of accidental exposure.
A typical lifecycle looks like this:
OAuth Login
│
▼
Access Token Issued
│
▼
Requests to MCP Server
│
▼
Token Expires
│
▼
Refresh or Reauthenticate
Short-lived tokens significantly reduce the amount of time an attacker could misuse a leaked credential.
The exact lifetime depends on the Authorization Server.
Access Token vs Refresh Token
These two token types serve different purposes.
| Access Token | Refresh Token |
|---|---|
| Used for API requests | Used to obtain new Access Tokens |
| Usually short-lived | Usually longer-lived |
| Sent to the MCP server | Sent only to the Authorization Server |
| Included in Authorization headers | Never sent with normal API requests |
Most users interact only with Access Tokens.
Refresh Tokens work behind the scenes to keep users signed in without requiring them to authenticate repeatedly.
Bearer Tokens vs API Keys
Although both authenticate requests, they solve different problems.
| API Key | Bearer Token |
|---|---|
| Usually static | Temporary |
| Often created manually | Issued automatically by OAuth |
| May never expire | Usually expires |
| Represents an application | Represents delegated user authorization |
| Simpler to implement | More secure for user-based access |
Bearer Tokens are generally the preferred solution whenever user identity and delegated authorization are required.
Common Authentication Errors
OAuth-protected MCP servers typically return standard HTTP status codes when authentication fails.
HTTP 401 Unauthorized
A 401 Unauthorized response usually means the server could not validate the Bearer Token.
Common causes include:
- expired token
- malformed token
- invalid signature
- missing Authorization header
- revoked token
The client usually needs to obtain a new Access Token before retrying.
HTTP 403 Forbidden
A 403 Forbidden response indicates that authentication succeeded but authorization failed.
For example:
- the user lacks permission to execute a tool
- access to a resource is restricted
- administrative privileges are required
Authentication and authorization are separate steps.
A valid token alone does not guarantee permission to perform every operation.
Security Best Practices
Bearer Tokens provide strong security when implemented correctly.
Follow these recommendations:
Always Use HTTPS
Bearer Tokens should only be transmitted over encrypted HTTPS connections.
Without transport encryption, intercepted tokens could potentially be reused.
Never Store Tokens in Source Code
Access Tokens should never be hardcoded into applications or committed to version control.
Instead, obtain them dynamically through OAuth.
Protect Authorization Headers
Application logs should avoid recording Authorization headers.
Accidentally logging Bearer Tokens can expose sensitive credentials.
Use Short-Lived Access Tokens
Short expiration times reduce the impact of leaked credentials.
Refresh Tokens can be used to obtain new Access Tokens without requiring the user to log in again.
Validate Every Request
Servers should validate Bearer Tokens for every incoming request rather than assuming previously authenticated clients remain trustworthy.
Continuous validation is a fundamental principle of secure OAuth implementations.
Want to analyze your API security?
Import your OpenAPI spec and generate a Security Report automatically.
Conclusion
Bearer Tokens are the foundation of OAuth authentication for remote MCP servers.
After a successful OAuth flow, clients include an Access Token in the HTTP Authorization header with every request. The MCP server validates the token, confirms its authenticity and permissions, and only then executes the requested operation.
Combined with HTTPS, short-lived Access Tokens, Refresh Tokens, and proper authorization checks, Bearer Tokens provide a secure and scalable authentication model for modern AI applications built on the Model Context Protocol.
Continue learning:
- OAuth PKCE for MCP — Learn how PKCE protects the OAuth Authorization Code flow.
- MCP OAuth — Understand OAuth authentication in the Model Context Protocol.
- Cursor MCP Authentication — Explore how Cursor authenticates with remote MCP servers.
- Cursor MCP Permissions — Learn how authenticated users are authorized.
- Cursor MCP Remote Server — Deploy secure remote MCP infrastructure.
- OAuth 2.1 MCP — Dive deeper into the OAuth 2.1 model used by MCP.