Dify Enterprise SSO with Okta: OIDC or SAML setup

How Dify Enterprise SSO with Okta fits your sign-in path

Okta is a supported identity provider for Dify Enterprise, so an organization running a self-hosted Dify Enterprise deployment can have staff sign in with their existing Okta accounts. Dify Enterprise SSO supports OpenID Connect, SAML and OAuth2, and it keeps two separate SSO scopes: one for workspace access, where builders and administrators sign in, and one for web app access, where people using published apps sign in. Each scope needs its own application configuration on the Okta side and its own settings on the Dify side, so the two must be planned together rather than treated as one login.

The Okta application and the Dify configuration must match for each scope. The values that have to agree include the protocol you select, the redirect or callback addresses Dify expects for that scope, and the user attributes Okta sends back. Because the callback addresses differ between scopes, a mismatch usually shows up as a failed sign-in for only one audience, which makes it easy to miss in testing. Before you start, confirm the exact field names, callback formats and session settings in the Dify Enterprise SSO documentation for the version you have installed, since the Enterprise docs are versioned and the menus and options can change between releases.

Ask your Dify Enterprise contact to confirm which SSO protocol and scope combinations your licensed version supports, and record who owns the Okta applications and the Dify administrator account that stores the configuration. Those decisions determine how you test each scope, who can change them later and what happens when an Okta application is rotated or recreated.

What you need before configuring Okta and Dify

Most of the delay in an Okta integration happens before anyone opens the Okta admin console. The cards below cover the license, the deployment baseline, the Okta access, the public address and the session secret, and each one should be confirmed in writing before the configuration work begins.

Dify Enterprise license

SSO is an Enterprise feature. The Community edition is limited to a single workspace and does not include SSO, so the Okta configuration cannot start on a Community install. Ask the licensing contact to confirm in writing that the license covers SSO, the number of workspaces you plan to use, and the support terms. The Enterprise license must be active before you test sign-in.

Enterprise-grade deployment baseline

Dify Enterprise is deployed on Kubernetes rather than the single-host Docker Compose layout. The resources checklist calls for Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Confirm that your cluster and managed services meet these minimums before scheduling the SSO work.

Okta tenant and application rights

You need an Okta tenant where an administrator can create and assign applications, and where you can define the groups that will map to Dify roles. Confirm your Okta edition and any tenant policies, such as sign-on rules, MFA requirements or network zones, with Okta and with your own Okta administrators. Policies set in the tenant can block sign-in in ways Dify logs will not explain.

Stable public HTTPS address

Okta redirects users back to Dify at callback URLs that must match exactly, so the public hostname has to be fixed before registration. Plan separate callback URLs for workspace sign-in and for web app sign-in, and plan a certificate that covers both. Changing the hostname later means updating the Okta application and the Dify configuration together.

Session secret and key handling

Dify uses a SECRET_KEY to sign session cookies and JWTs and to encrypt OAuth credentials. Changing it after deployment logs out all users, so generate it once, store it in your secrets manager and record who holds it. Confirm the handling procedure with your platform team before you enter the Okta client secret, because the encrypted credentials depend on this key.

Separate owners for each area

The Okta administrator, the Dify platform administrator and the network owner are often different people in a regulated organization. Agree on who creates the Okta application, who stores the client secret, who approves the DNS and TLS changes and who tests sign-in. Confirm the Okta version and tenant-specific settings with Okta and the current Dify documentation before you start, since both can change between releases.

Choosing OIDC or SAML for Dify with Okta

OIDC runs an OAuth2 authorization code flow in which Okta issues an ID token with claims about the signed-in user, and Dify Enterprise reads those claims to identify the person. It fits teams that already manage OAuth2 or OpenID Connect applications in Okta, want claims they can inspect and map, and want the same pattern they use for other internal tools. The Dify side needs the client ID, client secret and issuer URL from the Okta application, and the redirect URL registered in Okta must match the callback for the scope you are configuring.

Client credentials: the Okta application holds a client secret that someone must rotate and store, usually in your secrets manager.
Claims mapping: email, name and group values arrive as claims, so confirm the claim names Okta emits for the authorization server you use.
Callback per scope: workspace sign-in and web app sign-in each need their own registered redirect URL in Okta.
Token and session lifetimes: Okta and Dify both control how long sessions last, so review both before you set the session timeout.
Authorization server choice: the default and custom authorization servers differ in issuer and scopes, so pick one deliberately.

Check the callback paths and claim names in the Dify Enterprise SSO introduction for your release before you register the Okta application.

Dify Enterprise SSO with Okta setup sequence

This sequence takes a Dify Enterprise team from a confirmed public address to working Okta sign-in for each SSO scope, with assigned users admitted, unassigned users refused and session timeout tested. The result is a set of checks the platform team can repeat in staging before production users sign in.

Confirm the public URL and TLS
The platform team confirms the public address that users will open for Dify, that it resolves inside the networks your users work from, and that it serves a certificate your browsers trust. Okta returns users to addresses on this host after sign-in, so any later change to the hostname or certificate chain means updating the Okta settings as well. Record the final address in the change record before you create anything in Okta. The check: open the address in a clean browser session from a user network, confirm there is no certificate warning, and confirm the address matches what you intend to enter in Okta.
Choose OIDC or SAML for each scope
The identity lead decides the protocol for each scope the team needs, workspace access and web app access. The Dify Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with Okta among the named identity providers, so confirm in that documentation which options apply to each scope in your Enterprise version before choosing. Consider which protocol your security team already reviews for Okta, and which one your web app users will reach through embedded or external access. Record the decision per scope. The check: a written table that names the protocol for each scope and the Okta application type that matches it.
Create one Okta application per scope
The Okta administrator creates a separate application integration in Okta for each scope that the team plans to enable, using the protocol recorded in the previous step. Separate applications keep each scope's redirect settings and user assignments independent, so a change for web app users does not alter workspace sign-in. Name each application so that its scope is obvious in audit logs and in the Okta admin console. The check: each scope appears as its own application in Okta, with the protocol shown as configured and no shared client credentials between applications.
Copy Dify callback values into Okta
The Dify administrator opens the SSO settings for each scope and reads the redirect or callback values that Dify displays for that scope. The Okta administrator pastes each value into the matching Okta application, into its sign-in redirect settings, with no changes to the characters or path. Do not reuse one callback value across scopes, because each scope is expected to return users to its own address. Keep a copy of both values in the change record. The check: each Okta application lists exactly one callback for its scope, and a sign-in started from one scope completes only at that scope's address.
Enter Okta metadata or client credentials in Dify
For SAML, the Okta administrator exports the application metadata and the Dify administrator uploads or pastes it into the matching scope. For OIDC, the Okta administrator provides the client ID, client secret and issuer details, and the Dify administrator enters them in the scope's settings. Treat the client secret as a credential: store it in your approved secrets process and limit who can view it. Dify uses SECRET_KEY to encrypt OAuth credentials, so confirm that key is set before entry and that it is backed up under your key management controls. The check: Dify saves each scope without errors and shows the scope as enabled.
Map user identifiers and groups
The identity lead chooses which Okta attribute identifies each user in Dify, typically the email address, and confirms that the value Okta sends matches the identifier Dify expects in the SSO documentation. If your workspace roles depend on Okta groups, the Okta administrator adds those groups to the token or assertion sent to Dify, and the Dify administrator maps each group to its intended role or workspace. Keep the mapping list short and documented, because mismatched groups are a common cause of users signing in with the wrong access. The check: a test user signs in, and the profile in Dify shows the expected identifier and group-based access.
Assign test users in Okta
The Okta administrator assigns a small group of test accounts to each application, covering each role the mapping in the previous step produces. The administrator also keeps one test account unassigned to the application. Assignment in Okta controls which accounts can sign in through that integration, so this step tests whether Okta enforces the boundary before Dify is involved. Record which accounts are assigned and which are intentionally left out. The check: each assigned test account reaches Dify through its scope, and the unassigned account is refused by Okta before it reaches the Dify sign-in page.
Set timeout and test each scope
The Dify administrator sets the session timeout for the Enterprise SSO configuration, confirms the value against the SSO documentation for your version, and checks it against your organization's session policy. The team then runs sign-in and sign-out tests for each scope: sign in, use the application, sign out, and confirm the session cannot be reused. Wait out the timeout with an idle session and confirm the next request requires sign-in again. Note that changing SECRET_KEY after deployment logs out all users, so schedule any such change. The check: sign-out ends the session in each scope, and an idle session expires at the configured time.

Identity and group fields to map from Okta to Dify

This table lists the Okta attributes, claims and group assignments that Dify Enterprise needs to identify users and decide their workspace and web app access. Read each row as a question to answer before configuring the app integration, and confirm every claim name against the Dify Enterprise SSO documentation for your installed version, because names differ between OIDC and SAML. The main takeaway is that group mapping, not the sign-in itself, usually determines who ends up with the wrong access.

Okta source	Dify field or role	Scope	What to confirm
User identifier (Okta login or email)	Account identity used to match or create the Dify member	Workspace and web app	Which Okta attribute Dify reads as the unique identifier for each protocol, and whether it must be verified and unique across the tenant
Display name (first and last name)	Member display name shown in the workspace and audit views	Workspace	Which profile attributes are mapped, and whether a name change in Okta updates the existing Dify account
Email address	Email field used for notifications and account matching	Workspace and web app	Whether email is the identifier or only a contact field, and how Dify handles an address that changes after first sign-in
Group claim or group assignment	Workspace membership and the workspace role a user receives	Workspace	The exact group claim name for OIDC or SAML, the filter that limits which groups are sent, and how a user in several groups is resolved
Group-to-role mapping for each workspace	Role inside each Dify workspace (for example, builder or viewer)	Workspace	The role names available in your Dify version, and whether unmatched users receive no access or a default role
Attribute separating staff from external users	Decision on whether the user may enter the workspace or only use specific web apps	Web app	Which attribute or group marks external users, and how the web app access level treats a user who signs in through a different identity provider
Required claims per protocol (OIDC scopes or SAML assertion attributes)	Sign-in succeeds and attributes arrive intact	Workspace and web app	The required scopes or attribute statements for OIDC or SAML as listed in the SSO documentation, and whether a missing claim blocks sign-in or only leaves a field empty
Okta app assignments	Which users may start sign-in to Dify at all	Workspace and web app	Whether assignment is by user or group, and that every group used for role mapping is also assigned to the Dify app

Why workspace and web app sign-in need separate callback URLs

Dify Enterprise defines separate SSO scopes for workspace access, meaning the people who build, configure and manage apps, and web app access, meaning the people who use published apps. Each scope needs its own callback configuration in Okta, and the two should not share a callback or an Okta application by default. A single callback pointed at a single Okta application admits every user assigned to that application to both surfaces, so an end user who should only open a published app could reach the builder console, and the reverse mistake can lock out a builder who needs workspace access. Decide first which Okta groups belong to each scope, then build the Okta application and assignments around those groups.

Before you test anything, list the callback URLs that the Dify Enterprise console shows for each scope and record which Okta application owns each one. Keep the register alongside your Okta assignment rules so that a later change to one application does not silently affect the other scope. Confirm the exact fields and URL formats in the Dify Enterprise SSO documentation for your release, since those details change between versions and are not repeated here. Also confirm whether your Okta tenant needs a separate application for each scope, or whether the configuration you have chosen supports both from one application, and document that decision with its owner.

Test each scope with at least two accounts: one that should have access and one that should not. Use a builder account and a plain end-user account for workspace access, and an end-user account plus an account outside the permitted Okta group for web app access. Sign in through each callback, confirm that the denied account is refused or redirected, and check that the granted account lands on the correct surface. Repeat these tests after any change to Okta group rules, assignments or Dify SSO settings. Keep the results with your change record so that an auditor or colleague can see who was tested, against which scope and on what date.

Securing Dify Enterprise SSO with Okta

Getting Okta sign-in working is only part of the job. The controls below decide who can reach Dify, how long a session lasts, and how secrets and outbound traffic are protected once the integration is live. Confirm each setting name in the Dify environment reference and the SSO documentation before you change anything in production.

Restrict Okta app assignments

Assign the Dify application in Okta only to the groups that need workspace or web app access, rather than to the whole organization. Review those group memberships on a fixed schedule, because a broad assignment lets anyone in the directory reach sign-in. Confirm with your Okta administrator how group-based assignment interacts with the separate workspace and web app SSO scopes in Dify.

Store the client secret or certificate

Keep the OIDC client secret or the SAML signing certificate in a managed secret store, not in a shared file or chat thread. Record the date each credential was issued and the date it must rotate, and assign one owner to that record. Plan each rotation as a change with a tested window, since a credential mismatch stops every sign-in.

Match session timeout to policy

Set the Dify session timeout to match your organization's identity and session policy, and check that Okta's own session settings do not conflict with it. A timeout that is too long extends exposure on shared workstations, while one that is too short frustrates builders working in long sessions. Confirm the exact setting name and its unit in the Dify environment reference before you test it.

Plan SECRET_KEY changes

Treat SECRET_KEY as a value you do not change casually. It signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users. Schedule any change as a maintenance event with users notified, and confirm how the stored OAuth credentials are re-encrypted before you rotate it.

Keep outbound requests behind SSRF proxy

Route outbound requests from Dify through the SSRF proxy settings so that calls to identity endpoints and other services pass through a proxy that blocks internal and private IP ranges. Test that your Okta tenant URLs still resolve and connect through the proxy after any network change. Confirm the relevant setting names in the environment reference, since a misconfigured proxy can break sign-in silently.

Review Okta sign-in events

Forward Okta System Log events for Dify applications to your central logging or SIEM platform and review failed sign-ins, unexpected group changes and assignments to new users on a regular cadence. Pair these events with Dify's own logs so that an investigation can follow a user from the identity provider into the workspace. Confirm with your Okta and logging teams which event types and retention periods your policy requires.

Common Okta sign-in failures in Dify and how to fix them

This table pairs each common Okta sign-in symptom in Dify Enterprise with its likely cause and the check that confirms it. Start with the symptom that matches what users see, then verify the named log or scope configuration before changing any setting. Most failures trace to a callback URL, a group assignment, a rotated certificate or a timing mismatch, so the first check is usually the one that narrows the cause fastest.

Symptom	Likely cause	Fix and check
Okta shows an error after sign-in, or Dify returns to the login page	Callback URL in the Okta app does not match the callback for the scope being used in Dify	Compare the redirect URI in the Okta app with the callback shown for the workspace scope in Dify. Confirm in the Okta system log which URL was requested, then correct the entry in Okta.
Sign-in works for the workspace but fails when opening a published web app	The web app scope has its own callback and Okta app entry, and only the workspace one was configured	Check the web app scope settings in Dify and confirm its separate callback URL is registered in Okta. Test with a user who has access to that app in the Dify logs.
User authenticates in Okta but Dify denies access	The user is assigned to the Okta app but not to the group that the Dify access mapping relies on	Review the group assignments on the Okta app and the attribute or group claim Dify expects. Use the Okta system log to confirm the claim sent for that user.
SAML sign-in fails with an invalid signature message	Signing certificate was rotated in Okta, but Dify still holds the old certificate or metadata	Re-download the current metadata from the Okta app and update the identity provider settings in Dify. Confirm the certificate expiry date shown in Okta before and after the change.
Assertion rejected as not yet valid or expired	Clock skew between Okta, Dify API servers and the proxy or load balancer in front of them	Compare system time on the Dify hosts with an NTP source, then rerun a sign-in test. Check the Dify API logs for the timestamps reported in the rejection.
Users are signed out sooner than expected	The session timeout configured in Dify is shorter than the period users expect, or the Okta session policy ends first	Confirm the session timeout value in the Dify SSO settings and the Okta sign-on policy for the app. Compare timestamps of the sign-out events in the Dify logs with the Okta system log.
All users are signed out at once after a configuration change	SECRET_KEY was changed after deployment, which invalidates existing session cookies and JWTs	Restore the previous SECRET_KEY if the change was unplanned. Plan any future rotation as a scheduled sign-out, and tell users before it happens.

Questions buyers ask about Okta SSO for Dify Enterprise

What drives the cost of Okta SSO setup for Dify Enterprise?

The main cost driver is the amount of identity design in scope, not the clicks inside Okta. Workspace access and web app access are separate SSO scopes, and each one needs its own Okta app, callback URL and test cycle. Group design adds effort when Okta groups must map to workspace roles automatically instead of being assigned by hand. The Kubernetes footprint matters too, because Dify Enterprise runs on a cluster that must meet the versions and sizing in the resources checklist. A production identity change also carries change control work: a non-production test run, a rollback plan and an approval window. Fixed-scope quotes follow from a written scope. Dify Enterprise licensing is custom priced and is a separate cost from the implementation work. Ask for each scope and each Okta app to appear as its own line in the quote.

How long does Okta SSO setup for Dify Enterprise take?

The timeline is set in the written scope, and it depends mainly on your change calendar rather than on configuration effort alone. The items that most often set the pace are:

Access to a non-production Dify Enterprise environment and a test Okta tenant or test org
Change board approval windows for the production identity change
Availability of Okta administrators and the business owner who signs off on test results
Whether the Kubernetes deployment is already running at the version the SSO documentation expects

A team that books these items early can move through configuration and testing without waiting on each approval. Ask the partner to show the dependencies and the approval points in the schedule before work starts, so you can see which dates are fixed by your organization and which are fixed by the work.

What must our team provide before Okta SSO work starts?

Your team must provide access, a public address and test identities before configuration begins. The required items are:

Okta administrator access with rights to create applications, groups and sign-on policies
A public HTTPS address for Dify with a DNS name and a valid certificate, because the callback URLs in each scope must match that address exactly
Test users in several Okta groups, including one user who should be denied access
A Dify Enterprise license, because SSO is an Enterprise feature and the Community edition does not provide it

You should also name an Okta owner who can approve the sign-on policy and a Dify owner who can approve changes to the workspace settings. Confirm the exact list of access rights with the partner in writing before the first session.

Can our in-house team set up Okta SSO for Dify alone?

Yes, an in-house team can do this alone if it has Okta administration skills and works from the Dify Enterprise SSO documentation for its exact version. The main risk is getting a scope wrong. A callback URL copied into the wrong scope, or a missing callback, can block sign-in for every user or send users into an access level they should not have. These faults often stay hidden until someone tests with a standard user instead of an administrator. Your team should test each scope with a non-admin user from an allowed group and a denied user, and keep a documented rollback path. If your engineers have not run an Enterprise SSO change before, the cost of a partner is usually spent on the test evidence and the change record, which an internal team can also produce if it plans for them.

What does a partner deliver in fixed-scope Okta SSO work?

A fixed-scope engagement delivers written configuration, test evidence for each scope and a runbook. The written configuration records the Okta applications, groups, callback URLs and Dify settings for workspace and web app scopes, so the setup can be audited and repeated. The test evidence shows, for each scope, that allowed users sign in and denied users do not. The runbook covers routine tasks such as adding an application, rotating an Okta signing certificate and handling a sign-in failure. Scope, deliverables and timeline are agreed in writing before work starts, and anything outside that scope needs a separate written change. Ask for a sample of the evidence and the runbook outline during the quote stage so you know the format before you commit.

Should we choose OIDC or SAML for Okta and Dify?

Choose the protocol your Dify version and your Okta app patterns support cleanly, and confirm that choice in the SSO documentation for that version. The Dify Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2 as supported protocols, with Okta among the named identity providers. Factors to weigh include whether your Okta tenant already runs OIDC or SAML apps with a consistent claims model, how your security standard and existing review process treat each protocol, and how group information reaches Dify so role mapping works. Protocol choice also affects how session lifetime is enforced, so check the session behavior in your chosen protocol during testing. Record the reason for the choice in the configuration record, because auditors and future administrators will ask for it.

How does session timeout work with Okta sign-in in Dify?

Session timeout has two controls, one in Dify and one in Okta, and both need to match your policy. Dify sets how long its own sign-in session remains valid, and the exact setting name belongs in the environment variable reference for your version, so confirm it there before you change it. Okta sets its own session lifetime and idle timeout in the sign-on policy that applies to the Dify application. After a change, test that an expired session returns the user to Okta for sign-in. Also plan key changes carefully: according to the Dify environment reference, changing SECRET_KEY after deployment logs out all users, so schedule any rotation outside working hours and tell users in advance.

How DeployOpen scopes and delivers Okta SSO for Dify

DeployOpen plans, implements and documents Dify Enterprise SSO with Okta inside your own infrastructure, from the choice between OIDC and SAML to the handover of the running configuration. Engagements are fixed-scope, so the protocol, scopes, callback URLs and session behavior are agreed in writing before any configuration begins.

How we scope

Confirm whether your Dify Enterprise edition and Okta tenant support the OIDC or SAML path you intend to use.
Record which scopes need SSO: workspace access, web app access, or both, with each callback URL mapped to its scope.
Agree the session timeout, group mapping and test users in the written scope before implementation starts.

How we build

Register the Okta application and configure the redirect and callback URLs for each Dify scope in your environment.
Set the attribute mapping, signing settings and secret handling so that credentials stay in your own secret store.
Test sign-in, sign-out and session expiry for workspace and web app access with named test accounts and failed-login cases.

How we hand over

Deliver a configuration record covering protocol choice, callback URLs, timeout values and the Okta app settings used.
Document the steps to rotate client secrets or signing certificates and the effect of changing the Dify secret key.
Walk your identity and platform teams through the runbook so they can verify and troubleshoot sign-in without us.

How we support

Support after handover can be provided under a retainer that covers Dify upgrades and changes to the Okta configuration.
Re-test SSO flows after each planned Dify minor release, since releases arrive roughly monthly.
Ask any provider to confirm in writing which Dify edition, Okta feature and support terms their quote assumes.

Dify Enterprise SSO with Okta (OIDC or SAML)