Authorization Code or Client Credentials: Which OAuth Grant Should Your Bot Use?

The decision: whose authority does the bot use?

Before connecting a bot to an OAuth-protected tool, decide whether it should act for a person who authorizes access or as a separate application. The choice affects consent, scopes, audit attribution and how the connection can be revoked. Those effects depend on the tool and its authorization server; a grant name alone does not guarantee what an audit log will display.

An unattended bot makes this question practical. A scheduled task cannot complete a browser consent flow at run time, but a previously authorized connection might be renewable. A bot using client credentials can request a token without a user present only if the authorization server accepts that grant and the client has the required credentials and permissions.

Sources: RFC 6749: The OAuth 2.0 Authorization Framework, Authorization - Model Context Protocol (2026-07-28).

What each grant actually does

With authorization code, a user is redirected to an authorization server, grants access, and the client exchanges the resulting code for an access token. This is the usual shape when the bot needs to act on a particular user’s behalf. The authorization server decides token contents, scopes and whether a refresh token is issued; do not infer them from the grant name.

With client credentials, a confidential client authenticates to the authorization server and requests a token under its own authority, without a separate user authorization step. RFC 6749 defines this grant, but an individual authorization server is free to omit it or restrict its use. It may be suitable for a service identity that reads shared inventory, provided the tool’s policies allow that identity and grant.

For either grant, document whose access the token represents, the least scopes the task needs, how tokens expire or are revoked, and what the tool records for audit. Refresh-token availability, password-change effects, account-session behavior and service-account attribution are provider-specific. Test them with the actual tool before relying on them in operations.

Sources: RFC 6749: The OAuth 2.0 Authorization Framework, Authorization - Model Context Protocol (2026-07-28).

What the current MCP spec actually supports today

The MCP versioning page identifies 2026-07-28 as the current protocol version. Its authorization specification describes authorization for HTTP transports, discovery of the authorization server, client registration and token use. It does not by itself guarantee that every server accepts the client_credentials grant. The grant is part of OAuth, while actual support is a property of the authorization server and client registration.

Older MCP text can explain why readers encounter different advice. The 2025-03-26 authorization revision discussed both authorization code for a human user and client credentials for application-to-application access. The 2025-11-25 revision used authorization_code in a registration example. Those historical examples should not be read as the current protocol version or as a complete list of grants that all implementations support.

There is also an implementation distinction: the current MCP TypeScript SDK documents ClientCredentialsProvider for clients. That is useful when building a client, but an SDK capability does not make a particular tool’s authorization server support the grant. Inspect that server’s OAuth metadata and registration documentation, then test a scoped token request against the tool before promising an unattended connection.

Sources: Versioning - Model Context Protocol, Authorization - Model Context Protocol (2026-07-28), Authorization - Model Context Protocol, Authorization - Model Context Protocol, Client auth extensions - MCP TypeScript SDK, RFC 8414: OAuth 2.0 Authorization Server Metadata.

Worked example: a scheduled inventory-check bot (illustrative)

Imagine a bot that runs nightly, reads low-stock items from a warehouse tool and posts a team summary. It needs read-only access to shared inventory. Whether that access belongs to a named person or to a service identity is a policy decision for the warehouse system, not something the bot should guess.

If the warehouse authorization server supports only authorization code for this integration, an administrator could authorize a designated account once if the provider permits it. Before relying on that connection for nightly work, verify whether refresh tokens are issued, their expiration and revocation rules, and how a failed refresh surfaces. A password change or session logout might affect it under some providers, but neither outcome is universal.

If the server supports client_credentials for a service client and permits the needed read-only scope, the bot can request tokens using its own client authentication. Store the client credential securely, rotate it, and alert on token-request failures. The server can still revoke the client, change policy or reject a scope; a service token is not inherently permanent.

Start with the server’s metadata and integration guide. RFC 8414 makes grant_types_supported optional; when absent, its specified default is authorization_code and implicit, so omission is not proof of client-credentials support. Confirm any provider-specific extension and test the exact registration and token request before scheduling the bot.

Sources: RFC 8414: OAuth 2.0 Authorization Server Metadata, RFC 6749: The OAuth 2.0 Authorization Framework.

A short checklist before you wire the connection

Choose the identity first: is the bot acting for a specific consenting user, or may it use its own service identity? Define the minimum scopes and the audit and revocation behavior your team needs.

Then check the tool’s current authorization documentation and metadata. Verify the advertised grants, client registration method, required authentication, permitted scopes and token audience. Because grant_types_supported may be omitted from RFC 8414 metadata, use the standard’s default as a starting point and confirm any additional grant with the provider; do not treat a client SDK feature as server support.

Finally, run an end-to-end token request and a small read-only tool call, then test expiry and revocation behavior. Monitor failures and record a recovery path for the credential or consent flow. Correction, 2026-10-04: an earlier version of this article called MCP 2025-11-25 the current specification; the current published version is 2026-07-28.

Sources: Authorization - Model Context Protocol (2026-07-28), RFC 8414: OAuth 2.0 Authorization Server Metadata, Versioning - Model Context Protocol.