MCP authentication

MCP clients discover your authorization server through OAuth 2.1 metadata and RFC 9728 protected-resource documents. Authdog hosts the issuer per environment so you can protect MCP tool servers without building login UI.

Flow

1. The MCP client calls your resource without a token.
2. The resource responds with 401 and WWW-Authenticate pointing at protected-resource metadata.
3. The client loads metadata, starts authorize with PKCE (S256), and optionally sends a resource indicator (RFC 8707).
4. After consent, the client exchanges the code at the token endpoint and calls tools with the access token.

Client --(no token)--> MCP resource
MCP resource --401 + resource_metadata--> Client
Client --authorize + PKCE--> Authdog (hosted consent)
Client --token--> Authdog
Client --Bearer token--> MCP resource

Environment settings

In the console, open MCP Auth → Settings for your MCP project environment:

• Enable MCP Auth turns on default-resource and strict-resource behavior for that issuer.
• Default resource is applied when clients omit the resource parameter.
• Strict resource mode rejects authorize and token requests that omit resource when no default is configured.

Dynamic client registration and client-ID metadata (CIMD) toggles are stored per environment. When MCP Auth is enabled, the issuer registration endpoint honors DCR and CIMD toggles; CIMD clients use an https metadata URL as client_id.

Resource server integration

Use @authdog/mcp-sdk from the Authdog monorepo (packages/mcp-sdk). The AuthdogMcpAuthProvider class wraps token validation for Workers or Node MCP servers:

import { AuthdogMcpAuthProvider } from "@authdog/mcp-sdk"

const auth = new AuthdogMcpAuthProvider({
  env: {
    AUTHDOG_OIDC_ISSUER: process.env.AUTHDOG_OIDC_ISSUER!,
    MCP_PROTECTED_RESOURCE: process.env.MCP_PROTECTED_RESOURCE!,
    MCP_REQUIRED_SCOPES: "mcp:invoke",
  },
})

const result = await auth.validateAccessToken(request.headers.get("authorization"))

See MCP security and the console MCP module.

Enterprise SSO and MCP OAuth

MCP OAuth uses the same environment issuer as hosted sign-in and enterprise connections. There is no separate MCP-only SAML or OIDC stack: when Enterprise SSO is enabled for an environment, users signing in to MCP clients through Authdog follow the same IdP routing, MFA, and session policies as the account portal.

SCIM or HRIS deprovisioning (or deactivating a user in the console) revokes Connected Apps consents and invalidates outstanding OIDC access and refresh tokens for that user in the environment, so MCP clients cannot refresh after directory removal.

Audit and SIEM

Enable MCP_TELEMETRY=true on your MCP server (or hosted gateway) with an environment API secret (adenv_). The SDK sends runtime events to POST https://api.authdog.com/v1/mcp/events. They appear in Audit under category mcp_runtime and in Agents → Activity for MCP projects.

When AuthZEN or the trust store denies a tool, the runtime records MCP_TOOL_DENIED with decision: deny and a reason code (for example tool_not_allowed). Subscribe to MCP_TOOL_DENIED and related types in Notifications → Channels after you confirm them in Audit → Event Types.

Authdog indexes events for console search; long-term retention is your SIEM or webhook destination. See Audit logs and SIEM security events. Payload fields use snake_case inside event_payload (tool_name, decision, reason, server_id, …); raw tool arguments are never stored.

For how OAuth-only MCP compares to trust store, AuthZEN, and audit, see MCP OAuth vs platform stack.

Related

• Machine identity
• Agent sign-in
• Authentication