Skip to main content
By default, Dify calls an MCP server with a single, fixed workspace-level credential — every caller looks the same to the server. With identity forwarding turned on, each call also carries a token for the user who is currently running the workflow, so the MCP server can act on behalf of that real user (per-user authorization, auditing, and data scoping).
This page covers how to enable forwarding and what you need first. For the trust model and the full identity-provider / MCP-server requirements, see MCP User-Identity Forwarding.

​
Requirements

Before you enable forwarding, make sure the following are in place:
  • Enterprise edition with OIDC or OAuth2 SSO configured for the workspace (SAML is not supported).
  • Your identity provider issues a refresh token at login, so Dify can mint a per-call token for each user.
  • Your MCP server validates the forwarded token against the same identity provider and rejects unauthenticated requests.
These are summarized here. For the complete requirements — the shared-issuer rule, how the token audience is handled, and exactly what your MCP server must verify — follow the setup in MCP User-Identity Forwarding.

​
Enable forwarding

1

Enforce OIDC or OAuth2 SSO

Configure and enforce workspace SSO as OIDC or OAuth2. See Configure SSO Authentication.
2

Have each user sign in via SSO once

Each user must sign in through SSO at least once so Dify can later obtain per-call tokens on their behalf. Console/workspace users and published-Web-App end users are both handled automatically.
3

Turn on the toggle for the MCP provider

Go to Tools → MCP, select the provider, click Edit, enable Forward user identity, and save.The toggle appears only when SSO is enforced for sign-in (it is hidden on community editions and when SSO is not configured). It is per provider, so an admin decides in one place which MCP servers receive caller identity.
4

Verify

Run any workflow that calls the provider and confirm the MCP server receives the forwarded token and that it represents the running user.

​
How outbound calls change

When forwarding is active, Dify adds a dedicated header to each request to the MCP server, alongside (not replacing) any credential already configured on the provider: 
X-Dify-SSO-Token: <token representing the running user>
Your MCP server reads this header and validates the token. See MCP User-Identity Forwarding for what it must check.
Forwarding is not supported for Service API calls or scheduled (Cron) runs, which have no interactive user — don’t rely on it for those execution paths.

​
Troubleshooting

SituationWhat to do
The running user has never signed in via SSO, or their session can no longer be refreshedAsk the user to (re-)sign in via SSO
SSO is not configured or disabledConfigure SSO in the admin console
For the supported caller matrix and more detail, see MCP User-Identity Forwarding.