MCP OAuth and AI agent authentication: OAuth, PKCE or an API key?

Editorial team · updated 24 September 2026 · facts checked 24 September 2026

MCP OAuth is the authorization flow the Model Context Protocol defines for remote servers: OAuth 2.1 with PKCE, where the MCP server publishes protected resource metadata and the client requests a token bound to that server. Use it when an agent acts for a person; a scoped API key still fits local servers and your own backend.

On 24 September 2026 we re-read the current MCP specification (revision 2026-07-28), the OAuth RFCs it cites and the OAuth documentation of the communication providers in our dataset, and fetched each provider's public OAuth metadata documents. Nobody on the editorial team signed in to a provider or ran an agent against one. The config snippet below is copied from vendor docs and marked as untested.

API keys vs OAuth for AI agents: what each one protects against

An API key is a long-lived secret that acts as your account until someone revokes it. OAuth replaces it with short-lived access tokens issued by an authorization server, and the grant type decides who the token acts for. For an agent, the practical question is what happens when the credential leaks, or when the agent is tricked into using it for the wrong task.

Authorization code with PKCE is the delegated flow. The agent sends the user to the provider's consent screen, receives a one-time code, and exchanges it for tokens. RFC 7636 exists because public clients using this grant "are susceptible to the authorization code interception attack"; PKCE binds the code to a secret only the original client holds. The OAuth 2.1 draft (revision 16, September 2026) makes it the default: "Clients MUST use code_challenge and code_verifier", the plain method is prohibited, and the implicit and password grants are dropped.

Client credentials is machine-to-machine. OAuth 2.1 says it "MUST only be used by confidential clients", meaning a backend that can keep a secret. The token acts as the client itself, so it adds short lifetimes and scopes but no user consent. Twilio's own overview says the authorization code grant "offers stronger security than Client Credentials" because the user must authenticate and consent.

Device authorization (RFC 8628) covers agents on a server or in CI with no browser: the user confirms a code on their phone or laptop. Of the 27 providers in our dataset, only Bird documents it, and its auth.md names the use case: "for a headless agent".

A Bearer header is not OAuth. SendGrid, Mailtrap and SMTP2GO accept their API keys as Authorization: Bearer, and that key is still a static key. Our dataset keeps the two in separate fields for that reason.

Short-lived credentials also exist outside OAuth. AWS never sends the secret: each request is signed with IAM keys (SigV4), and temporary STS credentials expire on their own; Vonage application JWTs, signed with your private key, last 15 minutes by default and can carry an ACL that limits paths and methods.

How MCP authorization works in the 2026-07-28 specification

Authorization is "OPTIONAL for MCP implementations". When a remote (HTTP) server uses it, the server acts as an OAuth 2.1 resource server and the MCP client, such as Claude Code or Cursor, acts as the OAuth client. A local server that runs over STDIO "SHOULD NOT follow this specification, and instead retrieve credentials from the environment". That is why Mailgun's, Postmark's and ClickSend's local servers read an API key from an environment variable.

The authorization section runs in this order:

1. 401 with a pointer. The client calls the server without a token and gets 401 Unauthorized with a WWW-Authenticate: Bearer resource_metadata="…" header, optionally with the scope the operation needs.
2. Protected resource metadata. MCP servers "MUST implement" RFC 9728. The document at /.well-known/oauth-protected-resource names the authorization server.
3. Authorization server metadata. The client reads RFC 8414 or OpenID Connect discovery. If code_challenge_methods_supported is absent, the security considerations say the client "MUST refuse to proceed".
4. Client registration. Pre-registration first, then a Client ID Metadata Document (the client ID is an HTTPS URL pointing to a JSON file the client hosts), then Dynamic Client Registration, which the 2026-07-28 revision marks as deprecated.
5. Consent with PKCE and a resource parameter. The client sends S256 PKCE values and the server's canonical URI per RFC 8707, and must send it "regardless of whether authorization servers support it".
6. Issuer check. Before redeeming the code, the client compares the iss in the response with the issuer it recorded (RFC 9207), which blocks mix-up attacks.
7. Token use. The access token goes in the Authorization header of every request, never in the URL. The server must check the token was issued for it, and "MUST NOT pass through the token it received" to an upstream API.

Here is step 2 on a live server: the protected resource metadata Textmagic's MCP server returned when we fetched it on 24 September 2026 (reformatted, values unchanged). It names the authorization server and the nine scopes a client can ask for, from read-only mcp:sms:view to mcp:sms:send, which spends money.

{
  "resource": "https://mcp.textmagic.com",
  "authorization_servers": ["https://oauth.textmagic.com"],
  "scopes_supported": ["mcp:account:view", "mcp:sms:view", "mcp:sms:send",
    "mcp:contacts:view", "mcp:contacts:manage", "mcp:groups:view",
    "mcp:groups:manage", "mcp:tags:view", "mcp:tags:manage"],
  "bearer_methods_supported": ["header"]
}

The last rule matters for communication APIs. An MCP server in front of an SMS or email API holds its own upstream credential; it doesn't forward the token your client sent. The security best practices call that forwarding "token passthrough" and list wildcard scopes such as all and full-access among common mistakes.

Four revisions since March 2025 have defined or changed authorization, and older tutorials still describe the earlier ones:

Machine-to-machine access sits outside the core flow. The authorization extensions list Enterprise-Managed Authorization as stable and a client credentials extension as a draft.

Which messaging APIs support OAuth

The table sorts the 27 providers in our directory alphabetically. "REST API OAuth" is what your own code or agent can use against the provider's API; "MCP server sign-in" is what an MCP client does when it connects to the provider's official server. Rows checked on 24 September 2026 include documentation or metadata we re-read that day; the rest come from our dataset check of 23 September 2026.

Sources: provider pages and metadata documents listed at the end of this article; each provider card links the rest.

Eight providers document OAuth for their REST API, and only three of them let an agent act for any consenting user on messaging endpoints: Bird, Resend and Telnyx. Brevo's authorization code flow is limited to apps inside your own Brevo organization, with public apps "planned for a future release". Twilio's case needs a closer read. Its authorization code apps are organization-level, and their scopes cover managed users, role assignments and usage records. Messaging goes through account OAuth apps, which "only support the Client Credentials grant type" (the Twilio alternatives table marks which SMS APIs offer the authorization code grant).

Ten official MCP servers advertise OAuth sign-in, Brevo's only in its metadata, and Textmagic's and WATI's although their REST APIs don't offer OAuth. The metadata shows where OAuth is weaker than it looks:

• Single scopes. WATI's and Brevo's MCP metadata list one scope, all, and SendPulse's lists one, rest, so the consent screen can't narrow what the token does. Resend's guide says a client that omits scope "gets both scopes by default", emails:send and full_access. Textmagic and 360dialog split permissions finely, and Textmagic's guide says the assistant previews recipients, text and cost before each send.
• PKCE plain. The authorization servers of Infobip's MCP servers, Telnyx and SendPulse's MCP server still list plain next to S256. OAuth 2.1 prohibits it; the MCP spec requires S256 when the client can use it.
• Audience binding. Resend says RFC 8707 resource indicators are "accepted but ignored", so its tokens aren't bound to the MCP server by that mechanism.
• Discovery. SendPulse's MCP server serves no protected resource metadata at the well-known paths; its authorization server metadata sits on the MCP host, as the 2025-03-26 revision expected.
• Registration. Resend, Textmagic and 360dialog advertise Client ID Metadata Document support, the method the current revision prefers; the other seven list only a Dynamic Client Registration endpoint, which it deprecates.

Status, transport and auth for every MCP server are also in the AI readiness dataset, as CSV and JSON.

Why OAuth weighs 16 of 100 in our Developer & AI score

Since 24 September 2026, documented OAuth 2.0 is worth 16 of the 100 points in the Developer & AI component of our methodology, up from 6; scoped keys went from 10 to 5 and webhook signing from 12 to 7 in the same change. Developer & AI is 28% of the overall rating, so with the other criteria known, OAuth moves an overall score by about 4.5 points. OAuth offered only on the MCP server (Textmagic, WATI) or only to private apps (Brevo) counts as partial, half the points. Any OAuth 2.0 grant on the API counts in full, client credentials included; OAuth that exists only for a provider's MCP server counts as half.

The security reasoning is about what an agent session leaks. An agent reads files, issues and web pages, and any of them can carry instructions. A static key that ends up in a transcript, a log or a committed .mcp.json works until a person notices and revokes it. An OAuth access token expires on its own (Twilio's default is 1 hour, and Resend's example shows 900 seconds), and a delegated grant can be revoked for one client without rotating the key your production app uses. Our methodology treats a provider without any OAuth as missing one of those controls.

The counter-arguments are also in the data. A restricted key can be narrower than an OAuth token: Mailgun's Domain Sending Key only sends for one domain, and SMTP2GO keys list the endpoints they may call, while an MCP grant with the scope all covers everything. AWS and Vonage offer short-lived signed credentials without OAuth. That is why scoped keys and webhook signing stay in the score, and why each card shows the facts behind every point.

Practical rules for agent credentials

Pin the narrowest scope yourself. Claude Code lets you fix the scopes it requests for an MCP server with oauth.scopes, which takes precedence over what the server advertises. From v2.1.196, when nothing is pinned, it requests only the scope named in the server's WWW-Authenticate header or protected resource metadata. Resend's protected resource metadata names none, so pinning emails:send narrows a send-only setup. The shape below follows Claude Code's MCP docs; we did not run it:

{
  "mcpServers": {
    "resend": {
      "type": "http",
      "url": "https://mcp.resend.com/mcp",
      "oauth": { "scopes": "emails:send" }
    }
  }
}

With that token, expect Resend's domain, webhook and API-key tools to fail. Cursor's auth object also takes scopes, but it requires a pre-registered client ID, and without scopes Cursor reads scopes_supported from the authorization server.

Keep access tokens short and refresh tokens single. Where the provider lets you set the lifetime, as Twilio does for OAuth apps (1 minute to 30 days, default 1 hour), pick the shortest that fits the task. Resend and Bird rotate the refresh token on every use and treat reuse of an old one as compromise: Bird revokes the whole grant family, and Resend revokes the grant unless the rotation happened within the last minute. Run one refresher per grant, not several agents sharing a token file.

One credential per agent. Give each agent or MCP server its own OAuth grant or its own restricted key, so revoking one doesn't stop the rest and the provider's logs show which one acted. Don't copy one agent's token or key into another agent's config: a shared credential can only be revoked for all of them at once.

Know where revocation happens. Textmagic: Settings → My account → Connected apps → Delete connection. Bird: the connected applications view in the dashboard, which "invalidates the whole grant family". Twilio: Revoke under Authorized apps for authorization code apps, and deleting an Authorization Code app invalidates its access tokens immediately; for client credentials apps, rotate the secret or delete the app. Resend access tokens are JWTs that "can't be revoked individually"; revoking the refresh token ends the grant, and the last access token lives until it expires. Claude Code deletes its stored tokens when you remove a server or run claude mcp logout <name>; its docs don't say that revokes the grant at the provider, so revoke it there too.

Headless agents. For an agent without a browser, use the device grant where it exists (Bird), claude mcp login <name> --no-browser to finish sign-in from another machine, or client credentials held by a backend that the agent calls. Don't hand a CI job a delegated user token.

When OAuth isn't offered, use the narrowest key. Seventeen providers in the table document no OAuth for their REST API, and 14 of them have none on an official MCP server either. For those, a restricted key per agent, an IP allowlist and a short rotation cycle do most of the same work; the key options per provider are in the email MCP servers comparison and the vibe coding security checklist.

Related guides

• Email MCP servers compared: which email APIs ship an official MCP server, its auth and the narrowest key
• Vibe coding security checklist: exposed keys, MCP permissions, webhook signatures
• MCP servers and agent skills dataset: MCP status, transport and auth for all 27 providers
• PingMyUsers API and MCP server: query this directory's provider data from an agent, read-only
• SMS API rankings and transactional email rankings, where OAuth is one Developer & AI criterion

About this guide

The PingMyUsers editorial team wrote this article under the rules on the methodology page; the directory is operated by Sensaria AG in Switzerland. We did not sign in to any provider, register OAuth clients or run an agent; everything comes from public documentation, specifications and metadata documents. Providers appear alphabetically, and none paid for placement or reviewed the text. Report an error to contact@sensaria.ch; corrections are dated and sourced.

Methodology

On 24 September 2026 we re-read the MCP authorization section, its security considerations, client registration and discovery pages, the changelogs of revisions 2025-06-18, 2025-11-25 and 2026-07-28, the 2025-03-26 authorization page and the security best practices page. We checked the OAuth 2.1 draft (revision 16) and RFCs 6749, 7636, 8628, 8707, 9700 and 9728 at rfc-editor.org and the IETF datatracker. For providers, we re-read the OAuth pages of Twilio, Resend, Bird, Telnyx, Brevo, Sinch, Infobip, SendPulse, Textmagic and WATI, and fetched the public authorization server metadata and protected resource metadata of the ten official MCP servers that advertise OAuth, plus the REST API metadata of Bird, Resend and Telnyx. Other rows come from our provider dataset, checked 23 September 2026; where today's metadata differed from the dataset (Brevo's MCP OAuth, Twilio's grant split), the difference is logged in our editorial notes for the next card review. The question list behind the page comes from one pass of AI-search query research on ChatGPT and Gemini (45 queries kept).

Last updated

24 September 2026: first version. The MCP specification published four revisions between March 2025 and July 2026, and Brevo lists public OAuth apps as planned, so we re-check this page before publication on 10 November 2026, every six months after, and when a new MCP revision appears.

Frequently asked questions

What is MCP OAuth?

It is the authorization flow in the Model Context Protocol specification for remote MCP servers. The server acts as an OAuth 2.1 resource server, publishes protected resource metadata (RFC 9728), and accepts only access tokens issued for it. The client gets them through the authorization code grant with PKCE.

Does MCP require OAuth?

No. The specification calls authorization optional. Remote servers that use it should follow the OAuth flow, while local servers running over STDIO should read credentials from the environment instead, which is why most local servers take an API key in an environment variable.

Should an AI agent use OAuth or an API key?

Use OAuth with authorization code and PKCE when the agent acts for a person who can consent and later revoke access. Use client credentials or a restricted API key for your own backend. Either way, pick the narrowest scope or permission the provider offers.

What is PKCE and why does MCP require it?

PKCE (RFC 7636) makes the client create a secret verifier and send a hash of it with the authorization request, so a stolen authorization code can't be exchanged by anyone else. The MCP spec requires clients to use the S256 method when they can and to stop if the authorization server's metadata doesn't advertise PKCE support.

Is dynamic client registration deprecated in MCP?

Yes, since revision 2026-07-28. It stays for backwards compatibility, but the spec now prefers pre-registration and Client ID Metadata Documents, where the client ID is an HTTPS URL pointing to the client's own metadata file.

Is a Bearer token the same as OAuth?

No. Bearer is only the header format. SendGrid, Mailtrap and SMTP2GO accept static API keys as Bearer tokens; OAuth means the token came from an authorization server through a grant, expires and can be revoked separately from your key.

Which email and SMS APIs support OAuth?

In our dataset, Bird, Resend and Telnyx document delegated OAuth for their REST APIs; Infobip, SendPulse, Sinch and Twilio document client credentials for messaging; Brevo limits OAuth to private apps. Textmagic and WATI offer OAuth only on their MCP servers.