Dcipher MCP Server uses OAuth 2.1 with PKCE as its only authentication mechanism, providing a secure, standardized, interactive consent flow. Every request runs as you, using your existing Dcipher account - the server never mints or stores a separate long-lived credential of its own.
Supported authentication method
Authentication method | Description | Auth header |
OAuth 2.1 + PKCE | Interactive authorization-code flow. The client redirects you to Dcipher's login/consent screen; on success it receives a short-lived access token bound to your account. |
|
How access is enforced
Dcipher MCP Server doesn't use OAuth scopes to control what a tool can do. There's no consent-screen checkbox for "grant read access to knowledge bases" the way some OAuth providers work.
Instead, every tool call is re-checked against your normal Dcipher organization and project roles and permissions - the same rules that govern the Dcipher web app. If you can't do something in the app (for example, edit a project you don't own), the equivalent MCP tool call is denied too, following the same permission rules.
This means:
Granting a client access to Dcipher MCP Server doesn't widen what it can do beyond your own permissions.
Changing your role in Dcipher changes what MCP tools can do for you immediately, without re-authenticating.
There's nothing to configure at the OAuth layer to restrict a client to "read-only" - that's controlled by your Dcipher role, not by the connection.
Choose the right authentication method
Use OAuth 2.1 when:
- A person is present to complete the interactive sign-in
- You're connecting an AI client such as Claude Code, Claude Desktop, or ChatGPT
- You want the client to act with your exact existing permissions, nothing more
There is currently no supported path for unattended or background use (backend services, CI/CD, bots) - see the note above.