When Dify web app access for external users through SSO is the right design
If a team wants customers, partners or non-Dify staff to use a published Dify web app, the design needs Enterprise SSO scoped to web app access, and external users should not be placed in the workspace. Workspace accounts give people access to the app builder, prompts, knowledge bases and the data behind them, which is far more than an outside user needs to ask a question. The Dify Enterprise SSO documentation separates workspace access from web app access, so the identity provider can authenticate people into a published app without granting them a seat in the console. That separation is the feature the design depends on.
Workspace accounts remain the right choice for people who build, test, operate or govern apps: prompt engineers, knowledge base owners and administrators. Give those people workspace roles and let the identity provider manage them. Use web app access for everyone else, and decide before launch who belongs in each group. The Community edition does not offer this option. Its self-hosted edition is limited to a single workspace, and the pricing page lists SSO as an Enterprise feature, so an external-facing app with separate identity needs an Enterprise quote before the architecture is fixed.
Before committing, confirm with Dify how web app access levels map to your identity provider's groups and external accounts, and whether an external user can ever reach workspace pages through a shared login. Ask for the exact authentication flow for each scope in your version. Plan the data boundary now: test that an external session cannot read other apps, logs or knowledge base content, and document the result as part of your access review.
Which identity path fits which external audience
Customers rarely have corporate directory accounts, so the usual starting point is your own customer identity system or a product login service that already authenticates them for your portal. The Dify Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2 as the protocol options, and separates web app access from workspace access, so customer sign-in is configured on the web app scope. Confirm with the identity owner whether the customer login can issue OpenID Connect tokens that Dify can validate, and whether it can be reached from the browser paths customers use.
- Existing login service: Identify the system that already signs customers in and whether it supports OpenID Connect.
- Self-registration rules: Ask who creates accounts, whether sign-up is open, and whether accounts need verification before first use.
- Claims passed to Dify: Agree which user identifier, email and group claims Dify receives, and which ones are not needed.
- Session length: Set the timeout with the identity owner, since customers and staff have different tolerance for re-login.
- Support and lockout: Define how password resets and locked accounts are handled without involving your workspace administrators.
Check with the identity owner which protocol the customer login actually supports before you commit the design.
Partners usually belong to another organization, so their identity sits in a directory you do not run. The likely sources are the partner's own identity provider, a federation between organizations, or a shared external identity service that you operate for several partners. SAML and OpenID Connect are the common federation protocols, and the Dify Enterprise SSO documentation names both among its options. Whether a given partner identity provider can be trusted for a given web app is a decision for your security team and the partner's administrators together.
- Federation agreement: Document which partner organizations are trusted, the contact for each, and how trust is revoked.
- Protocol per partner: Record whether each partner offers SAML or OpenID Connect, since one partner may differ from another.
- Attribute mapping: Confirm which attributes identify the partner user and which group or domain claim limits access to a specific app.
- Offboarding: Agree how a partner's staff leaving the partner organization is reflected on your side, because your team may not receive a leaver event.
- Shared-tenant risk: Confirm whether partners would share one identity source, and if so, how one partner's accounts are kept out of another partner's apps.
Check with each partner's identity owner which protocol they can offer and who maintains their side of the trust.
Some staff, such as contractors, shared-service teams or staff in a unit that is not licensed for workspace access, need to use a published app without a Dify workspace account. Their identity is normally in your corporate directory, which is often Microsoft Entra ID, Okta or an on-premises directory exposed through a federation service. Because these users are employees, the directory owner already manages their lifecycle, and the question is usually how to limit them to web app access only. Microsoft Entra ID, Okta and GitHub are named as example providers in the Dify Enterprise SSO documentation, so confirm whether your directory is one of them or can be bridged to one of the listed protocols.
- Directory source: Confirm which directory holds these staff and whether it is reachable over OpenID Connect or SAML.
- Group-based access: Agree which directory group grants access to each web app, so access follows group membership rather than individual grants.
- Separation from workspace roles: Confirm that web app sign-in does not grant builder or workspace administrator rights.
- Leaver handling: Ask how directory deprovisioning reaches Dify, and whether SCIM provisioning is in scope for these users.
- Conditional access: Ask whether existing multifactor and device rules in the directory apply to the Dify sign-in.
Check with the directory owner which group and claim names they will provide before the app access design is finalized.
Web app access options and when each fits
This table compares the access levels a published Dify web app can use, the SSO scope each one relies on, who can change the setting and how much data each level exposes. Read it as a ladder from most restricted to most open, and confirm the exact menu labels in your Dify version before you write the access policy.
| Access level | SSO scope needed | Who can change it | Data exposure risk |
|---|---|---|---|
| Specific members or groups | Web app access via the enterprise identity provider, with group membership synced to the app | Users with the permission to manage the app's access settings, confirmed in your role model | Lowest; only named identities reach the app, so suits a pilot with a known user list |
| All platform members | Web app access for any authenticated workspace member | Users with the permission to manage the app's access settings, confirmed in your role model | Moderate; any account in the platform can open the app, including staff not meant to use it |
| Authenticated external users | Web app access scope for users who sign in through a separate external identity provider, not workspace accounts | Users with the permission to manage the app's access settings, confirmed in your role model | Moderate to high; depends on how the external identity provider enrolls and verifies users, and what the app can retrieve |
| Public | No sign-in required for the web app | Users with the permission to manage the app's access settings, confirmed in your role model | Highest; anyone with the link can use the app, so knowledge base content and prompts need review before publishing |
| Where the setting lives | Confirm whether the access level and SSO scope are set per app or per workspace in your version | Confirm the exact role or permission name in your Dify version | Check the configured level again after every upgrade and after any change to knowledge base sources |
Setting up external web app sign-in step by step
This sequence takes a published Dify web app from a workspace-only setting to one that external users can reach through their own identity provider. Each step ends with a check that confirms external accounts reach the app and stay out of workspace pages.
Confirm the Enterprise edition and license
The platform owner confirms that the instance runs Dify Enterprise with a license that includes SSO. The self-hosted Community edition is limited to a single workspace and does not offer Enterprise SSO, so the Dify pricing page is the first check. Ask the vendor to confirm in writing that the web app SSO scope is included in your license. The step is complete when the admin console shows SSO settings for both the workspace and web app scopes, and the license terms are filed with the change record.
Choose the protocol and identity provider
The security architect selects OpenID Connect, SAML or OAuth2 and confirms that the identity provider can issue sign-in for accounts that belong to customers, partners or contractors. The Enterprise SSO introduction lists these protocols and named providers such as Microsoft Entra ID and Okta, and the choice should match your existing external identity setup. Record the protocol, the provider tenant or organization, and who administers it. The step is complete when that decision is approved and written down with its owner.
Register the web app SSO scope with the provider
The identity administrator creates an application registration in the identity provider for the web app scope only. Copy the callback URLs exactly as the Dify Enterprise SSO documentation gives them for that scope, because the workspace scope uses different callback URLs. Do not reuse the workspace registration. The check is a sign-in attempt to the provider's test page for this registration, which should return to the Dify sign-in path without errors.
Enter the web app SSO settings in Dify
The Dify administrator enters the client identifier, secret and provider endpoints in the web app SSO settings. Store the client secret in your secrets manager and enter it only once in the console. Dify uses SECRET_KEY to encrypt stored OAuth credentials, so confirm that this value is set and backed up before you save. Changing SECRET_KEY later logs out all users. The step is complete when the settings save and the web app SSO option appears on the sign-in page for the web app scope.
Map claims and groups to the external audience
The identity administrator decides which claims or groups the provider sends and which of them grant access to the web app. Keep the external audience in a group that is separate from workspace members, so that an external sign-in does not create or imply a workspace role. Document the claim names and group values in the change record. The check is a test sign-in with a user from the external group and a user outside it, where only the first should reach the app.
Publish the app with the external access level
The app builder opens the app's access settings and selects the authenticated external users level, then publishes the app. Limit the permission to change this setting to a named role, because changing access is what exposes the app. Confirm the access level saved and that the published link shows the sign-in step. Record the app name, the access level and the person who approved the change.
Test with an external test account
Create a test account in the identity provider that belongs only to the external group and has no workspace membership. Sign in through the published web app and confirm the app opens and that answers work as expected. Then sign in with the same account to the workspace console and try the workspace pages and API routes directly. The check passes only if the external account cannot open any workspace page, and that result is recorded with the time of the test.
Record evidence and hand over the configuration
The platform owner collects the test results, the protocol decision, the callback URL record, the claim mapping and the access setting into one change record. Store secrets only in the secrets manager and remove any copies from tickets or chat. Schedule a periodic review of the external group membership with the identity team, and confirm who receives sign-in alerts. The step is complete when the change record is approved and the on-call team has the sign-in settings and rollback steps.
How external users stay apart from workspace data
External users of a Dify web app hold a different identity from your workspace staff, so the controls that keep them apart sit in several places: the identity scopes, the roles they receive, the data the app can reach, the secrets that sign their sessions, and the outbound paths a tool call can take. Review each control before the app is shared outside your organization.
Separate web app scope from workspace scope
Dify Enterprise SSO documents separate scopes for workspace access and web app access. Configure the web app scope with its own identity provider settings and callback URLs so that a successful external sign-in never grants a workspace session. Test with an external test account and confirm that the Dify console remains unreachable from that session.
Keep external identities out of workspace roles
An external user should never receive a workspace role such as editor or admin, even if the identity provider sends a group claim that matches an internal group name. Map external groups only to web app access, and review group mappings whenever a new identity provider source is added. Ask your identity team to confirm which claims reach Dify and which are dropped.
Review what the app can read
A web app inherits the knowledge bases, workflow nodes and connected tools it was built with, so an external user can trigger anything the app can reach. Before publishing, list each knowledge base and tool the app uses, confirm that none holds internal-only documents, and remove unused connections. Exported DSL files do not carry knowledge base content, so this review must happen on the live app.
Protect SECRET_KEY and OAuth credentials
The SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users. Store it in your secrets manager, restrict who can read the deployment environment, and record the rotation procedure before the first external user signs in. Plan any rotation as a coordinated logout event.
Confirm the SSRF proxy blocks internal ranges
Tool calls triggered by an external user are outbound requests made by the Dify server. The SSRF_PROXY settings route those requests through a proxy that blocks internal and private IP ranges, so confirm the setting is active in your deployment. Test by pointing a tool at an internal address from a test app and verify the request fails before any external user has access.
Questions teams ask before opening a Dify app to outside users
What drives the cost of opening a Dify app to external users through SSO?
The cost depends on the written scope: how many identity providers and callback scopes are involved, whether the external identity provider is already running, how many apps need external access, and how much testing and documentation the team wants. Dify Enterprise, which carries the SSO feature, is custom priced, and the pricing page lists the self-hosted Enterprise edition as custom priced with no public figure. DeployOpen does not publish a price list, so ask for a quote built from a written scope that names each app, identity provider, environment and deliverable. Ask which parts are one-time (configuration, testing, runbooks) and which recur (upgrades, credential rotation, support).
How long does setting up external user access usually take?
Duration depends mostly on the identity provider, the number of environments and how fast your administrators can approve changes. A setup with an identity provider your team already runs, one production environment and a small number of apps is far shorter than a setup that needs a new identity provider, staging and production, and security review. No general duration is published for this work, so ask for a timeline in the written scope that lists the dependencies: identity provider admin access, callback URL approval, test accounts and change windows. Schedule time for end-to-end testing with real external accounts before any launch.
What must our team provide before the work starts?
Plan to supply four things before work begins:
- Administrator access to the identity provider, such as Microsoft Entra ID, Okta or Keycloak, to register the Dify application and set its claims and groups
- Approval of the callback URLs for the web app scope, which must match the exact address of each Dify instance
- Test accounts that represent each external user type, including a user who should be denied access
- A named owner who makes decisions on access levels, sign-out behavior and who may publish apps
Missing any of these usually moves the timeline, so confirm them before the quote is signed.
Can our team set this up without outside help?
Yes, if your engineers have experience with OpenID Connect or SAML, your identity provider administrators can make the changes, and someone can test the sign-in path from outside your network. The Dify Enterprise SSO documentation lists the supported protocols and separate SSO scopes for workspace access and web app access, so the work is documented. The risk lies in the details: keeping external users separate from workspace data, setting the correct web app access level, handling session timeouts and verifying that a removed external user loses access. An outside team is most useful when it writes the scope, tests the isolation and leaves a runbook your staff can follow.
Why do we need the Dify Enterprise license for external user sign-in?
The Dify pricing page lists SSO as a feature of the self-hosted Enterprise edition, while the Community edition is free and limited to a single workspace. The Dify Enterprise SSO documentation covers the web app scope that external users sign in through. Before you buy, confirm with Dify which features your license includes, how the license applies to your number of workspaces and whether it covers the environments you plan to run. DeployOpen does not resell licenses, and the license terms come from Dify. The Dify Open Source License also forbids operating a multi-tenant environment without written authorization, so separate external user groups from workspace data in a way the license allows.
What ongoing work follows after external users go live?
Expect recurring work in four areas. Dify releases minor versions roughly monthly, so plan a regular upgrade cycle, back up before each upgrade and check .env.example for new variables. Rotate the secrets and client credentials used by the identity provider integration on a schedule your security policy sets. Review web app access lists when staff or partner members change, and confirm that departing external users lose access. Monitor sign-in failures and logs for unusual activity. Ask for these items in the quote so that upgrades, rotation and access reviews are scoped as recurring support rather than assumed.
Does opening a Dify app to external users change our compliance evidence?
It adds evidence you need to keep current. Auditors will want to see who can reach each app, how access levels were chosen, how external identities are separated from workspace identities, and how access is removed. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask your assessor which evidence they expect and agree on the list before the build starts, so access reviews, configuration exports and test records are captured as the work proceeds.
What the Dify docs say about web app and workspace scopes
The Dify Enterprise SSO documentation separates sign-in into two scopes: one for workspace access, which governs staff who build, operate and administer apps, and one for web app access, which governs who can open a published web app. Each scope is configured on its own, so a single identity provider can serve both, but the two decisions are different. For external users, the web app scope is the one that matters. Before you design anything, read the Dify Enterprise SSO introduction and confirm which protocols (OpenID Connect, SAML or OAuth2) and which callback addresses your version expects for each scope.
Keeping the scopes apart protects workspace data. An external customer or partner who signs in through the web app scope should receive a session that reaches the published app and nothing else. The risk to plan for is a shared identity provider application or group that accidentally grants workspace-scope access to people who only need one app. Ask your Dify administrator to confirm, in a test workspace, that a user authenticated only for web app access cannot open the console, the app editor, the knowledge bases or other apps. Also confirm how session timeouts and sign-out behave for each scope, since the two scopes may expire at different times.
If your organization runs the Community edition, the SSO scopes described here are not available, and the sign-in options are different. The Community options are covered on the page for Dify Community edition login options without SSO, which is the next read for that case.
How DeployOpen scopes and delivers external Dify app access
DeployOpen plans, implements, tests and documents external access to Dify web apps inside your own infrastructure, with the identity provider, web app access levels and workspace boundaries agreed in writing before build work starts. Engagements are fixed-scope, and ongoing support is available as a retainer once the apps are live.
How we scope
- Written scope lists which apps external users reach and which identity provider signs them in.
- Scope records the external user groups, their permitted apps and who approves access changes.
- Scope names the Dify edition and deployment target, since web app SSO depends on Enterprise licensing.
- Scope confirms where external identity data is stored and which workspace data stays out of reach.
How we build
- We configure the web app access level for each published app, separating external users from platform members.
- We connect the chosen identity provider to the web app SSO scope, keeping it distinct from workspace sign-in.
- We test sign-in, sign-out and denied access with test accounts for each external user group.
- We check that external sessions cannot open workspace, console or knowledge base pages.
How we hand over
- You receive configuration records for the identity provider, callback addresses and access level settings.
- Runbooks cover adding, removing and reviewing external users and rotating the signing secrets safely.
- Test evidence shows each access rule was checked, ready for your security or compliance reviewers.
- Knowledge transfer sessions walk your administrators through daily tasks and the upgrade checklist.
How we support
- Retainers cover identity provider changes, Dify version upgrades and re-testing of external access rules.
- We review access settings after each Dify release, since platform changes can affect web app behavior.
- Support requests follow the agreed scope, and new external user groups are quoted as separate work.
