Dify SCIM provisioning with Okta or Entra ID

How Dify SCIM provisioning with Okta or Entra ID keeps workspace access current

SCIM 2.0 provisioning handles the account lifecycle and group membership, while SSO handles sign-in. If you run Dify Enterprise and want accounts and groups to follow Okta or Entra ID without manual invites, you need both: SSO decides how people authenticate, and SCIM tells Dify which users exist, which groups they belong to, and when they should be removed. Keeping these two concerns separate in your design makes it easier to see why a person can or cannot reach a workspace on a given day.

The setup centers on two inputs: a SCIM base URL from your Dify Enterprise instance and a bearer token that authenticates your identity provider to that endpoint. Treat the token as a credential with the same handling as other service secrets: store it in your identity provider's configuration only, record who generated it, and plan how you will rotate it. Before you describe or configure the endpoint, the supported attributes, how group names map to Dify roles, and whether the token is shown once and how it can be regenerated, confirm each of these in the Dify Enterprise SSO introduction and against the release you will deploy. Ask your Dify contact to confirm the same points for your edition if the documentation differs.

Before enabling sync, decide which Okta or Entra ID groups will drive workspace membership and which Dify roles they should map to, and run a test with a small group of accounts. Verify that a new user is created with the expected groups, that a group change in the directory is reflected in Dify, and that a disabled account loses access. Record the results, because the same checks become your evidence when an auditor or internal reviewer asks how leavers are removed.

What you need before connecting Okta or Entra ID to Dify

SCIM provisioning only works once the Dify Enterprise foundation, a working SSO setup and the identity provider's admin access are all in place. Each card below names who owns the item and what to verify before you touch the provisioning settings.

Dify Enterprise edition license

SCIM is part of the Enterprise edition, not the free Community edition. The Enterprise edition is custom priced, so the license and its scope come from a written quote. Confirm with Dify that your license covers SSO, multiple workspaces and the features you plan to use before you plan the provisioning work. Ask who holds the license and how renewals are handled.

Kubernetes, Helm and database versions

The Enterprise resources checklist sets the minimum versions: Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later and Redis 6 or later. Your platform team owns these. Verify each version in the target cluster and confirm that the PostgreSQL and Redis instances are reachable from the Dify namespace, because SCIM user and group records are stored there.

Qdrant and object storage

The Enterprise checklist requires a Qdrant vector database and S3-compatible or cloud object storage. These do not provision users, but a deployment that is not healthy will fail sync jobs in ways that look like identity problems. Your infrastructure team owns the Qdrant cluster and bucket. Confirm both are running, backed up and reachable before you begin the SCIM test.

Working SSO for the workspace

SCIM sits beside SSO and does not replace it. Users must already sign in through Okta or Entra ID using the workspace SSO scope before provisioning can be verified end to end. Your Dify administrator owns this configuration. Test a single account from the identity provider, confirm it lands in the correct workspace, and record the callback URL you registered.

Identity provider admin rights

Your identity team needs rights to create an enterprise application in Entra ID or a custom app integration in Okta, to assign users and groups, and to view provisioning logs. Entra ID and Okta both use roles that can be scoped narrowly. Confirm who will configure the provisioning connector, who approves the bearer token and who can pause provisioning during an incident.

HTTPS reachability and an Enterprise admin account

The identity provider calls the Dify SCIM endpoint over HTTPS from its own cloud, so the endpoint must be reachable from the public internet or through the approved egress path, with a certificate the provider trusts. Your network and security team owns the ingress rule and certificate. Separately, name one Enterprise admin account to generate the one-time bearer token, and store the token in your secrets manager immediately.

Why SCIM and SSO solve different parts of access

SSO and SCIM answer different questions, so a Dify Enterprise deployment needs both. SSO decides who can sign in right now: when a user opens Dify, the identity provider checks their password, MFA and session, then hands Dify an assertion or token. SCIM 2.0 works earlier and later in the lifecycle. It creates the user record in Dify before the first login, updates attributes such as name and email, adds or removes group membership, and deactivates the account when the person leaves. Group membership is what matters for access, because workspace roles are granted to the groups SCIM populates, so the identity provider stays the single place where joiners, movers and leavers are handled.

If a team configures only SSO, sign-in works but Dify has no independent record of who should exist. Accounts are typically created on first login, so a former employee who is disabled in the directory is blocked at the identity provider, yet any Dify account they already hold, along with its workspace memberships and group assignments, can remain in the Dify database. Admins then have to find those accounts by hand, and users who were never granted a role may hold no access but still appear in member lists. If a team configures only SCIM, accounts and roles are synchronized but sign-in still needs a working SSO connection, and the team has to confirm how Dify behaves when a user is deactivated mid-session. Confirm in the Dify Enterprise SSO documentation, which lists separate SSO scopes for workspace access and web app access, whether each scope needs its own callback URL in the identity provider before you plan the cutover.

Configuring SCIM in Dify and the IdP, step by step

This sequence connects Dify Enterprise to Okta or Entra ID so that users and groups are created, updated and deactivated from the identity provider. Each step ends with a check you can record, from a successful connection test to a single-user create, role and deactivation test before any wider sync.

Enable SCIM provisioning in the admin area
A Dify Enterprise administrator turns on SCIM provisioning in the admin area of the Enterprise instance. Confirm first that SSO already works with the same identity provider, because provisioning creates and updates the accounts that SSO signs in. Record the provisioning fields the admin area displays, including their exact labels, since the Okta and Entra steps refer to them. Check the Dify Enterprise SSO documentation for any prerequisites that apply to your version. Done when provisioning shows as enabled and the base URL field is populated.
Copy the base URL and generate the token
Copy the SCIM base URL exactly as the admin area shows it, including the full path, into your change record. Generate the bearer token from the same screen. The token is shown once, so copy it at that moment into a controlled, temporary location and keep the page open until the copy is saved. Ask Dify how the token is reissued or rotated, because that behavior decides your rotation runbook. Done when the base URL is recorded and the token is held in a controlled location for the next step.
Store the bearer token in a secrets manager
The platform or security team places the bearer token in your organization's approved secrets manager, with read access limited to the administrators and systems that configure provisioning. Record the secret's path and its rotation owner in the runbook, but never the token value. Clear the temporary copy from clipboards, notes, tickets and chat. Done when the provisioning administrator can retrieve the secret and the token no longer appears in any shared channel.
Configure the Okta provisioning app
An Okta administrator opens the Dify application integration, enables provisioning, and enters the SCIM base URL and the token retrieved from the secrets manager. Review which lifecycle actions are enabled for create, update and deactivate, and confirm that username, email and display name map to the attributes Dify expects. Run the test connection and save its result. Done when Okta reports a successful connection. If the test fails, the error should identify the failing call, such as an authentication or URL problem; correct that item before retrying.
Configure Entra ID enterprise application provisioning
A Microsoft Entra ID administrator opens the Dify enterprise application, sets the provisioning mode to automatic, and enters the same base URL and token. Run the connection test, then review attribute mappings so that users match on an identifier that aligns with the identity used for SSO. Hold the full sync until the pilot steps are complete. Done when Entra reports a successful connection, or returns an error that names the failed call, which you resolve before continuing.
Assign a small pilot group
Create a small pilot group in the identity provider that contains a few accounts, including the one you will use for the single-user test. Assign the group to the Dify provisioning application in Okta or Entra ID. Document the workspace and role that Dify should apply to pilot members, using a clear group naming convention such as dify-pilot (illustrative name). Done when the application's assignments list shows the expected members and the role mapping is written down.
Run a single-user test and verify
Select one pilot user, confirm group membership, and trigger provisioning. In Dify, confirm that the account appears in the expected workspace with the role your design specifies, and that sign-in through the configured SSO path works. Then deactivate the test user in the identity provider and confirm the account is deactivated in Dify, since deprovisioning is the check teams most often skip. Done when creation, role assignment and deactivation each match the design. Keep the provisioning logs as evidence for the change record.

Which IdP attributes and groups map to Dify users and roles

This table compares the identity fields Okta and Entra ID send for each user and group, and the Dify user field or workspace role each one feeds. Read it as a checklist to agree with your identity team before the first sync, and confirm exact attribute names and group-to-role behavior against the current Dify Enterprise SCIM documentation for your version.

Field	Okta source	Entra ID source	Owner of the decision
User identifier (unique key)	Okta user ID or the username used as the SCIM externalId	Entra object ID or the userPrincipalName used as the SCIM externalId	Identity team, agreed with the Dify admin
Email address	Primary email attribute on the user profile	Primary email, mapped from the mail attribute	Identity team; confirm which value Dify uses as the login
Display name	displayName or first and last name combined	displayName from the user object	Dify workspace admin
Active flag	Okta user status, pushed as active true or false	accountEnabled, pushed as active true or false	Identity team; confirm deactivation behavior in Dify
Group membership	Okta groups assigned to the Dify app, pushed as group resources	Entra groups assigned to the Dify enterprise app, pushed as group resources	Platform owner with the identity team
Group-to-workspace role	Mapped by group name or ID in the Dify SCIM configuration, confirm role options	Mapped by group object ID in the Dify SCIM configuration, confirm role options	Dify workspace owner who approves access
Nested or dynamic groups	Often unsupported or flattened; test before relying on them	Nested groups may not sync as expected; test before relying on them	Identity team; decide before go-live

Where Okta and Entra ID setups differ

In Okta, Dify is added as an application integration in the admin console, and provisioning is configured on that integration after single sign-on is working. Okta separates who can sign in from who is provisioned, so the application must be assigned to the people and groups who should have Dify accounts. Confirm in Okta's current documentation which app option fits a SCIM 2.0 connection to Dify Enterprise, because the menu names and options change between releases.

Application creation: Create the Dify integration in the Okta admin console and confirm whether it uses the SSO settings and the provisioning settings from the same integration.
Provisioning mode: Enable API-based provisioning on the integration, then enter the base URL and the one-time bearer token that Dify Enterprise issues. Use the connection test before you save, and store the token in your secrets manager because Dify shows it once.
Group push or assignment: Users are provisioned when they are assigned to the application. Groups are only pushed if group push is configured and the groups are assigned to the application, so confirm how Dify expects group membership to be represented.
Attribute mapping: Review the profile mappings for the username, email, display name and active status, and check which attributes update on each profile change. The unique identifier Dify uses must match the value Okta sends.
Test-user flow: Assign one test user, confirm the account appears in Dify with the expected role, then unassign that user and confirm the account is deactivated in Dify.

Before wider rollout, check that the deactivation test passed and that the group membership you expect appears in the Dify workspace.

What happens to a leaver's content when the account is deactivated

The content a leaver built does not leave with them, but the account that owns it does. When Okta or Entra ID unassigns a user or disables the account, the SCIM request reaches Dify Enterprise and deactivates the matching member. The sign-in path closes at once, but the apps, knowledge bases, API keys and scheduled runs tied to that person stay in the workspace until someone reassigns or removes them. Treat deactivation as a cutoff for access, not a cleanup of content. Before the first leaver, confirm in the current release exactly how Dify handles each object type, because the behavior for ownership, shared resources and automated runs is what determines whether a departure breaks a production app.

Work through each category with a disposable test account in a staging workspace. Create an app, a knowledge base, a service API key and a scheduled or triggered run under that account, then deactivate it through the IdP and watch what changes. Record whether the app keeps running and which owner it shows, whether the knowledge base remains searchable by other members, whether the API key still authenticates, and whether the scheduled run still executes. Confirm also whether a deactivated member can be restored with the same ID, since a rehire may otherwise create a duplicate identity. Repeat the test after each Dify upgrade, because the release notes and the App management documentation are the places where ownership rules change first.

Plan ownership transfer before the first leaver, not during the offboarding ticket. Assign a named owner or team group to every production app and knowledge base, and keep service API keys issued to shared service identities rather than to individuals where the platform allows it. Write down who reassigns resources, who approves the change, and how that is logged, so the record shows the transfer happened before access was removed. Ask your DeployOpen or internal team to confirm whether the exported DSL of each app contains everything needed to rebuild it if an owner is lost, since DSL files omit third-party API keys and knowledge base content.

Protecting the SCIM endpoint and the bearer token

The SCIM endpoint can create, change and remove Dify Enterprise accounts, so the bearer token is effectively an administrative credential. The cards below cover how to store and rotate it, how to limit the identity provider app and the people who can reissue it, and how to verify provisioning activity over time.

Store and rotate the bearer token

Treat the token as a privileged secret. Paste it directly into the identity provider's SCIM connector configuration and keep no copy in tickets, chat or shared notes. Store it in your organization's approved secrets manager and record who holds it. Plan a rotation step that updates the token in the identity provider at the same time it is replaced in Dify, so provisioning does not fail silently during the change. Confirm with Dify Enterprise support how rotation is performed in your version, since the token is shown once.

Scope the identity provider app

In Okta or Entra ID, assign only the group that holds Dify users to the SCIM-enabled application. Users outside that group are never pushed to Dify, so a broad assignment cannot create accounts you did not intend. Check that nested or dynamic groups resolve to the membership you expect, and review the assigned group after each organizational change. Pair this with a named owner for the group so membership changes are reviewed by the team that runs Dify.

Serve the endpoint only over HTTPS

The SCIM base URL carries the bearer token on every request, so it must only be reachable over TLS. Terminate TLS at a proxy you control, reject plain HTTP at the edge, and confirm the certificate chain is trusted by the identity provider's outbound service. Check that the endpoint is not exposed on a public address if your identity provider can reach it privately. Test with a request made outside the identity provider to confirm the connection is refused over HTTP.

Limit who can regenerate the token

Anyone who can generate a new SCIM token can replace the one the identity provider uses, which either breaks provisioning or hands a new credential to someone outside the identity team. Restrict the Enterprise administrative role that performs this action to a short named list, and require a change ticket for each regeneration. Review that list whenever an administrator changes role, and confirm which admin role controls token generation in your Dify Enterprise version.

Review provisioning audit records

Provisioning changes made through SCIM should be traceable to the identity provider and the time they happened. Export the Dify Enterprise logs your team uses for administration and compare account creations, role changes and deactivations against the identity provider's own system log. Investigate any account created or elevated without a matching assignment change. Confirm with Dify Enterprise which events are logged, how long they are retained and where they can be exported.

Plan the SECRET_KEY change window

The SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and the Dify environment reference says changing it after deployment logs out all users. Rotating it is therefore a session-wide event, not a SCIM task, and it should be scheduled with the business owners of the workspaces. Before the window, confirm that identity provider sign-in will work after users log in again, and that any stored OAuth credentials are re-entered or re-encrypted as your version requires. Record the window and the rollback steps in your change calendar.

Why SCIM calls fail or leave accounts active

This table lists the failures teams most often hit when provisioning Dify Enterprise from Okta or Entra ID, with the likely cause, the diagnostic step and the fix for each. Read it when a user is missing, a role is wrong, or a leaver still has access, and work down the diagnostic column before changing configuration. Most of these faults trace back to the token, the mapped email attribute or a push setting that was never enabled.

Symptom	Likely cause	Diagnostic step	Fix
Provisioning requests rejected with authentication errors	The bearer token was regenerated or expired, or the old token is still stored in the identity provider	Check the identity provider's provisioning logs for 401 responses, then confirm which token value is saved in the app's provisioning settings	Generate a new token in Dify Enterprise, store it in the identity provider only, and retest the connection
Users not created in Dify	The email attribute is missing, empty or mapped to a different field than Dify expects	Open one failed user in the identity provider's import log and compare its email value with the attribute mapping	Correct the attribute mapping so the email value reaches Dify, then re-run import for the affected users
Users created with the wrong sign-in identity	The username or external ID mapped to the identifier differs from the value used at SSO sign-in	Compare the identifier in the SCIM payload with the identifier in the SSO assertion or token claim for the same user	Align the identifier mapping across SCIM and SSO, then reconcile the affected accounts before further syncs
Group membership does not change workspace roles	Groups are not pushed or assigned to the application, or group names do not match the mapping Dify uses	Confirm the group appears in the app's push groups list and check whether the membership appears in Dify after a sync	Assign and push the required groups, map each group to its intended workspace role, and verify with one test user
Duplicate accounts after a user's name or email changes	The identity provider sent a new identifier for the same person, so Dify created a second record	Search Dify for both accounts and compare their creation dates and linked identity values	Keep the stable identifier constant in the mapping, merge or disable the duplicate, and document the rule for future renames
Leaver still has active access	Unassignment or deactivation was not pushed, so Dify never received the deactivate request	Check the identity provider log for the deactivate event and confirm push settings for deactivation are enabled	Enable deprovisioning push, deactivate the user in the identity provider, then confirm the account is disabled in Dify
Leaver has signed-in sessions after deactivation	Existing sessions or tokens remain valid until they expire	Test sign-in with the leaver's account and review the session timeout configured for SSO	Revoke sessions where Dify supports it, shorten session lifetime to your policy, and record the residual window for auditors

Questions buyers ask before hiring help with SCIM

What drives the cost of SCIM provisioning work with Okta or Entra ID?

The cost follows three things: the identity model, the number of groups and workspaces, and the testing scope. The self-hosted Community edition is limited to a single workspace, while Enterprise, which adds SSO and multiple workspaces, is custom priced, so multi-workspace provisioning starts with an Enterprise license (current pricing). Identity model complexity covers nested groups, extra attribute mappings and how IdP app assignments decide who gets access. Each group-to-workspace mapping adds design, configuration and verification work. Testing scope ranges from a few test users to a full run covering create, update, group change, deactivation and removal on both Okta and Entra ID. Most of the cost is one-time design and testing, while re-testing after Dify upgrades and ongoing support recur. Ask for a quote built on a written list of groups, workspaces, identity providers and test cases.

How long does SCIM setup take to reach a tested pilot and full rollout?

No duration is fixed for this work, so the timeline should come from the written scope and be confirmed in the quote. A pilot usually needs a running Dify Enterprise instance, a configured IdP application, a small test group and verified deprovisioning. Full rollout adds the remaining groups and workspaces, change control on the IdP side and a review of who receives access in each workspace. Ask for named milestones: pilot exit criteria, the test case list and a rollout order that moves group by group. Platform readiness also sets the starting point. The Enterprise resources checklist lists Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later and Redis 6 or later, so an environment missing any of these adds lead time before SCIM work can begin (resources checklist). Confirm which of these components already exist in your environment before agreeing on dates.

What does SCIM work need from our Okta or Entra ID and Dify admins?

Your identity team needs administrator rights to create the SCIM application in Okta or the enterprise application in Entra ID, assign the groups to provision and approve the attribute mappings. Someone must own the service account or identity used for sync and the process for rotating its credentials. Your Dify Enterprise admins need console access on the instance, a decision on workspace structure, and a method to generate the bearer token and store it in your secrets manager, since the token is shown once. They also need to confirm which workspace roles each group should receive. Agree beforehand on group naming, which group owns which workspace, who may generate tokens and how often they rotate. Assign a named approver for group-to-role decisions so access changes have a record. Confirm the exact token behavior in the Dify Enterprise SSO and provisioning documentation before the first configuration session.

Can an internal team set up Dify SCIM provisioning without a partner?

An internal team can do it if it has IdP administrators who have built SCIM connections before, access to a Dify Enterprise instance and people who can operate Kubernetes and Helm. The harder parts are rarely the first connection. They are the leaver test cases, reconciling accounts that already exist locally, and a rollback plan if a group mapping removes the wrong access. Check whether your team has a test IdP tenant and a staging Dify instance, since testing against production users carries risk. A partner adds value when you need a fixed written scope, a tested pilot, documentation that your auditors and security reviewers can follow, and a clear handover. DeployOpen implements self-hosted platforms inside your own cloud accounts or data centers, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

Does SSO alone remove leavers from Dify, or do we need SCIM?

SSO alone does not remove leavers from Dify. It controls whether a person can sign in through the identity provider at the moment they authenticate. Dify Enterprise SSO documentation describes separate scopes for workspace access and web app access, so each scope needs its own check. A disabled IdP account blocks new SSO sign-ins, but existing workspace memberships, resource permissions, shared web app grants and service API keys can remain until someone changes them. SCIM deprovisioning is the mechanism that carries an IdP change into Dify so membership is updated without a manual step. Confirm in your environment whether a SCIM deactivation ends active sessions, what happens to API keys the leaver created, and whether any local accounts still exist. Local accounts need a separate removal process.

How do we test that deprovisioning works before go-live?

Write test cases that follow one identity through its full life. Create a test user in the IdP and confirm the account appears in the expected workspace with the expected role. Change the user's group and confirm the workspace role changes. Then unassign or deactivate the user and confirm that sign-in fails and that workspace membership and web app access are removed. Check for service API keys or shared links the test user created, and record what remains. Run the full set in a staging instance first, then repeat a smaller set in production during the pilot. Keep the results as dated evidence with the IdP configuration version. Before you start, confirm which audit or provisioning events Dify Enterprise records, so you know which log entries prove each step and which steps need manual verification.

How DeployOpen scopes and delivers Dify provisioning

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including identity integration for Dify Enterprise. For SCIM provisioning with Okta or Entra ID, we agree the user and group scope in writing first, then build and verify the sync and deprovisioning path in your environment.

How we scope

Written scope listing which identity provider, user attributes and groups will sync into Dify Enterprise
Confirmation of your Dify Enterprise edition and deployment target before any provisioning work starts
Agreed handling of the one-time bearer token, its storage and who is allowed to rotate it
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins

How we build

Configuration of the SCIM 2.0 base URL and provisioning connector in Okta or Entra ID, tested against a non-production workspace
Group-to-role mapping designed with your identity team so membership changes take effect predictably in Dify
Test cases for joiners, movers and leavers, including deprovisioning of a user who still owns published apps
Verification evidence captured so your team can repeat the checks after upgrades or identity changes

How we hand over

Runbook covering token issuance, rotation, revocation and where each setting lives in the identity provider
Documented provisioning and deprovisioning flow for auditors, security reviewers and the operations team
Knowledge transfer sessions with the administrators who will run the integration day to day
Clear list of open items, such as any identity provider features you need to confirm with the vendor

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Review of sync behavior when Dify releases change the Enterprise administration or identity surfaces
Re-testing of provisioning and deprovisioning after identity provider tenant or policy changes
Quotes follow from the written scope, so ask for the retainer terms that match your change rate