Please use the form below to provide your feedback. Because your feedback is valuable to us, the information you submit in this form is recorded in our issue tracking system (JIRA), which is publicly available. You can track the status of your feedback using the ticket number displayed in the dialog once you submit the form.

IDP Compatibility

  • reference
Compare OAuth support across popular identity providers for use with the Couchbase MCP Server.

The Couchbase MCP Server acts as an OAuth 2.1 resource server. It works with identity providers (IdPs) that can issue JWT access tokens carrying the server’s scopes. Whether a given IdP fits depends mainly on how it handles scope strings.

Scope Compatibility — The General Rule

The server’s default scopes are couchbase-mcp:read and couchbase-mcp:write. You can remap these with CB_MCP_OAUTH_SCOPE_READ_LABEL / CB_MCP_OAUTH_SCOPE_WRITE_LABEL to match the naming convention used by a given identity provider. For more information, see Environment Variables.

  • Works out of the box: IdPs that let you define a scope string verbatim, or whose fixed scope format the custom scope labels can match. The token can carry the configured read scope, the write scope, or both.

  • Needs a different IdP: IdPs whose scope catalog the custom scope labels still cannot match.

  • Not suitable: providers that issue opaque (non-JWT) tokens.

They cannot act as JWT resource-server authorization servers for custom scopes.

Per-Provider Support

OAuth support across popular identity providers is not consistent. The level of support varies from one IdP to the next. Differences include which methods a provider offers (M2M, non-DCR, DCR) and details like the scope format it emits. No single behavior applies across providers, so use the following table as a reference guide when operating with an IdP and a particular method.

This table describes support for OAuth client registration and machine-to-machine flows — it does not cover scope-string compatibility. A provider marked No can still work with the server if it issues JWTs with the required scopes directly, or via the custom scope labels described in Scope Compatibility — The General Rule.
Authorization server Machine-to-Machine (client credentials) Non-DCR (manual / pre-registered clients, user flow) DCR (Dynamic Client Registration)

Auth0

Yes

Yes

Yes

Descope

Yes

Yes

Yes

Stytch

Yes

Yes

Yes

Keycloak

Yes

Yes

Yes

Microsoft Entra ID

No

Yes

No

Okta

Yes

Yes

No

AWS Cognito

No

Yes

No

WorkOS / AuthKit

No

No

Yes

Google Identity

No

No

No

GitHub

No

No

No

Discord

No

No

No

See Also