Dify web app access control levels: who can use each published app
Before a Dify web app goes live, the team has to decide who can reach it, and that decision is made per app, not per workspace. The access setting on a published web app controls whether it is limited to specific members or groups, open to all platform members, opened to authenticated external users, or made public. Teams should choose the most restrictive level that still lets the intended users work, then confirm the setting on the staging instance before launch, because a public link is easy to share and hard to recall. The setting is changed by a user with permission to edit and publish the app, so the people who can alter access should be named in the same plan.
The levels matter most when an app leaves the builder's team. A workflow that summarizes internal policy documents should normally stay with named members or a group, since its knowledge base reflects internal material. An app for customers or partners needs an external path, and the team must decide whether those users sign in at all. Public access suits only content the organization would publish anyway. Treat the pre-launch test as a real check: sign in as a user from each intended group, confirm an outsider is refused, and record the result. Ask the vendor or your own environment which levels your edition and version offer, because the available options depend on both.
Dify Enterprise web app sign-in is a separate SSO scope from workspace sign-in, so connecting the identity provider for builders does not automatically secure end users of a published app. The Dify Enterprise SSO documentation describes distinct scopes for these two purposes, and each needs its own configuration and callback. Confirm in the Enterprise documentation for your version how web app SSO maps identity provider groups to app access, and test it with a non-builder account. Self-hosted Community deployments should check their own sign-in options before assuming any app-level restriction exists beyond the levels shown in the console.
The access levels Dify offers for a published web app
Dify lets a builder choose who can open each published web app. The levels run from a named set of members or groups to anyone with the link, and each depends on a different identity source and carries different risks. Choose the most restrictive level that fits the audience, and confirm the exact labels in the Dify version you run.
Specific members or groups
This is the default for a newly published web app. Only the members or groups you add can open it, and each person signs in with their workspace account. It suits internal tools with a known audience, such as a support team's drafting assistant. Check that group membership is maintained by a source you trust, either by hand or through SCIM provisioning, because a stale group keeps old access alive. Confirm the default and the group picker wording in the app management docs for your version.
All platform members
Every member of the workspace can open the app at this level. The identity is the same workspace account used to build apps, so the audience changes whenever someone joins or leaves the workspace. Use it for broad internal tools where the whole workspace is the intended audience. Builders and end users then share one permission boundary, so review which knowledge bases and tools the app can reach before you choose this level.
Authenticated external users
External users are people outside your workforce, such as customers or partners. They sign in through an identity provider connected for web app access rather than through a workspace account. The web app SSO scope is separate from the workspace scope, so external sign-in should not grant workspace access. Confirm which protocols and identity providers your edition supports, and test that external users cannot reach builder screens or other apps.
Public access
Anyone with the link can use the app with no sign-in, so no user identity reaches the app or your logs. Treat it as an internet-facing service. The main risks are unmetered model spend, prompt abuse, and exposure of anything the app can retrieve from a knowledge base or call through a tool. Before choosing it, confirm the rate limit and moderation options in your version and decide what the app may access when it is called anonymously.
Which access level fits each kind of app
This table compares the access levels against the audience, data sensitivity, identity source and exposure risk of each app type. Start from the app's data and tools, then check who can reach it, since the more people outside your directory can open an app, the more the knowledge bases, tools and prompts behind it need review first. Confirm the exact access options and permissions in your Dify version before you publish.
| App type | Access level that usually fits | When it does not fit | Decide before publishing |
|---|---|---|---|
| Internal tools | Specific members or groups, mapped to your identity provider groups | Staff outside the mapped groups need the app, so membership becomes a manual exception list | Which groups own the app and who may change its access |
| Partner-facing apps | Authenticated external users through a separate identity provider | Partner staff need workspace data or builder access, which external users should not get | Partner identity source, offboarding trigger and internal systems the app can reach |
| Customer-facing apps | Authenticated external users, with public access only for low-sensitivity content | The app reveals internal prompts, retrieval content or tool access to anonymous visitors | Abuse and cost controls at the edge and who answers for model output |
| Demos and pilots | All platform members for internal showcases, public only with synthetic data | The demo runs on production knowledge bases, customer records or live model keys | Whether demo data is synthetic and when the app is unpublished |
| Apps on confidential knowledge bases | Specific members or groups only | All platform members can open the app and query content they are not cleared to see | Which retrieval sources attach to the app and who approved them |
| Public FAQ or marketing bots | Public, with a narrow knowledge base and no tools attached | The app can call tools, read files or write to records, since anonymous use then reaches those actions | Whether any tool, file or write action is attached and how it is monitored |
Which permission changes an app's access level
Changing who can use a published web app is a permission of its own, separate from the permission to build or edit the app. Treat it as a distinct decision when you design roles, because a person who can refine prompts or workflows should not automatically be able to open an app to all platform members, to external users or to the public. The access setting sits on the app itself, so the question to answer before go-live is which roles can open the access dialog and save a change, and who approves that change. Confirm the exact role names and what each one can do in the app management documentation for your version, since names and permissions have changed between releases.
Dify's workspace roles determine who can create, edit, publish and manage apps, and the access level is then controlled through those same roles. In a Community deployment, which is limited to a single workspace, the practical lever is simply who holds an editor or admin role, so separation depends on how few people hold those roles. In Dify Enterprise, custom roles and permission templates let you define a role that can publish or configure an app without holding the rights to change its access, or the reverse. Test this with a non-admin test account before launch: attempt to change the access level of a published app and confirm the control is refused or visible only to the intended group.
Write the separation down as a short RACI-style table for each production app, naming who builds, who deploys a new version, and who grants or changes access. Review it whenever an app moves from a test workspace to production, and when someone changes role. A common failure is that the team that built an app keeps admin rights long after handover, so the access level can be changed without the owner or security team knowing. Ask your Dify administrator to show you the audit or activity history for access changes in your version, and confirm whether that history is retained where your compliance team expects it.
How to set and verify web app access before launch
This sequence moves a published Dify web app from an unclear sharing setting to one that has been chosen, assigned and tested. Each step produces a decision or evidence that the app owner and your security or compliance reviewers can check.
Define the audience for each app
The app owner, with a business sponsor, writes one sentence naming who must use the app: a specific team, all platform members, customers or partners outside the company, or anyone who holds the link. The sentence also records why that audience needs the app. The step is done when every app planned for web access has an agreed audience statement, and any app without one stays out of general use until the statement exists.
Select the least open access level
Choose the level that serves the audience from the options: specific members or groups, all platform members, authenticated external users, or public access. Start with the most restrictive level and move outward only when the audience cannot be served otherwise. Exact menu labels change between releases, so confirm them in the App management documentation for your version. The step is done when the chosen level and a short reason for rejecting each more open level are recorded.
Assign members or groups
For the specific members or groups option, add the named accounts or groups from the approved roster. Where your identity provider already maintains the group, assign that group so membership changes follow the source system. Confirm with your SSO setup that group membership reaches Dify before relying on it for access. The step is done when the assigned list matches the roster from the first step and the app owner has initialed it.
Confirm who can change access
List the workspace roles and app-level permissions that allow someone to change the access level or add members. Keep that group small and separate from people who only edit prompts or workflows. If custom roles are available in your edition, use them to narrow this permission. The step is done when the permission holders are written down, the app owner has approved each one, and a test account without the permission cannot open the access setting.
Test as an allowed user
Open the app link in a private browser window, signed in as a test account from the audience. Confirm that the sign-in path matches the chosen level, the app loads, and a test prompt returns a response. Note the test account, the date and the result. The step is done when the allowed user reaches the app without seeing workspace pages or settings that the audience should not use.
Test as a denied user
Sign in with an account outside the audience, such as a workspace member who is not in the assigned group. Open the same link and confirm the app refuses access, and that the user cannot reach it through a chat or share URL. If access succeeds, stop and revert to the previous level before anyone else uses the app. The step is done when each type of denied account you tested has a recorded result showing the refusal.
Test anonymous and external paths
For external-user or public levels, open the link with no signed-in account and review what an anonymous visitor can see and send. Check that the app does not expose workspace-only pages, app settings or links to other apps. Someone other than the builder should review this view. The step is done when any unexpected exposure has been fixed and the visitor view has been tested again.
Record approval and retest changes
Save the chosen level, the assigned roster, the permission holders, the test results and the approver in the change record for the app. Repeat the denied-user test after any change to the access level, the roster or the permission holders. The step is done when the record is complete, linked to the launch ticket, and each later change has its own retest entry.
Security risks in web app access control
A published Dify web app is only as tightly held as its access level and the links that point to it. The risks below share a root cause: access decisions that are easy to widen, hard to notice, and tested only from inside the workspace. Each card names a risk and the check that keeps it contained.
Public links shared beyond the audience
A web app set to public can be opened by anyone who holds its link, and links are forwarded in chat threads, tickets and slide decks long after the original audience has changed. Ask who owns each public app, why it is public, and which audience it was built for. Review public apps on a fixed cadence and move any that no longer need open access to specific members or groups. Confirm the exact access labels in your Dify version, because menu wording changes between releases.
Embedded apps and blocked identity pages
Teams often embed a web app in an intranet page or partner portal with an iframe. If the identity provider's sign-in page refuses to render inside a frame, users see a blank or broken view and may switch the app to a looser access level to make it work. Test each embedded app in the browsers your users run, and check the identity provider's framing settings before go-live, not after the complaint arrives.
The link acting as a credential
For a public or externally shared app, possession of the URL is often the only control, so the link works as a bearer credential. It can be copied into search indexes, browser history, referrer headers and screenshots. Treat each shared link as a secret with an owner, and document where it was published. When a link is exposed, the fix is to change the access level or retire the app, so plan that path before an incident forces it.
Access changes that go unlogged
Changing an app from specific members to all members, or to public, can be a single menu action. Without a record of who made the change and when, a widened app is found only when someone reports a data exposure. Ask for an audit trail of access changes, export it to your central log store, and alert on any move toward a broader access level. Confirm in your version which events are logged and how long they are kept.
Testing access from outside the workspace
Checks run by an app builder who is already a workspace member do not show what an outsider sees. Test each access level from a session with no workspace role, from an unauthenticated browser, and from a signed-in user outside the permitted group. Repeat the tests after any change to identity provider groups, since group membership can drift from the intended audience.
Session signing and forced logouts
The SECRET_KEY environment setting signs session cookies and JWTs and encrypts OAuth credentials. Treat it as a deployment secret, not as an access control, and store it in your secrets manager. Changing it after deployment logs out all users, so plan the change as a maintenance event with users notified, and do not rotate it casually to revoke one person's access.
Questions teams ask before setting web app access
Can a Community edition Dify instance restrict web apps to specific groups?
Confirm this against the current Community docs before you design around it. The Dify materials tie group-based web app access to Enterprise SSO, which has a separate SSO scope for web app access, while the Community edition is documented as a single workspace with its own login options. If your Community version cannot assign web app access by group, you can keep each app limited to workspace members, or place an authentication layer in front of the app with a reverse proxy. That proxy is part of your infrastructure, and your team must operate it. Test with a non-admin account in each case before you publish.
What makes setting web app access take longer across many apps?
The effort rises with how many distinct audiences the apps serve, not with the raw count of apps. Each published app needs one access level, and every group named in an access rule must already exist in the identity source. Effort increases with the number of groups and nested memberships, the number of apps that serve external users, and whether access is set by hand in the console or driven by group membership from the identity provider. Apps that share an audience can follow one written access matrix, which keeps review short. Each external audience adds an identity path and its own test cycle. Ask for an inventory of apps, owners and intended audiences before you agree on scope.
Can our team set web app access alone, or do we need a partner?
Your team can set access alone if it has a Dify administrator, access to the identity provider and time to test each audience. A partner adds the most value when access must follow the identity provider automatically, when several identity sources or external audiences are involved, or when the design must be documented for an assessment. DeployOpen implements and documents this kind of work for self-hosted platforms in your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Whichever route you choose, decide who writes the access matrix, who configures the console and who signs off the tests.
How long does setup take with different identity sources?
No duration is supplied for this work, so confirm it against your own environment with the vendor or partner. The main variable is the identity source. A single OpenID Connect or SAML provider with clean groups involves fewer decisions than a setup that needs group clean-up, a second identity provider or a separate path for external users. The Enterprise SSO documentation lists Microsoft Entra ID, Okta and GitHub as example identity providers, and each needs its own callback configuration for workspace and web app scopes. Also plan for change approvals in your identity team, change windows and the test accounts you need. Ask for each identity source, each SSO scope and each test to be listed in the written scope.
What does the access work need from our team?
Three roles are needed. An identity administrator owns the groups, the SSO connection and the test accounts. App owners decide who should use each app and confirm its access level. A Dify administrator makes the changes in the console and keeps the access record. Each audience needs test accounts: a member of each group that should have access, a user outside those groups and, where it applies, an external user. Plan time for the identity team to create or clean up groups and for app owners to review the matrix. Also agree who approves access changes after go-live, because each group membership change alters who can open an app.
Does making a web app public change its data exposure?
Yes. A public app can be opened by anyone with its link, without signing in, so its inputs, outputs and any knowledge base content it can retrieve become reachable by people outside your organization. The Dify app export excludes knowledge base content, but that does not limit what a running public app can retrieve. Review which knowledge bases, tools and variables the app uses, what users may type into it, and how conversations are retained in your settings. Then test the public link from a browser that is not signed in. For illustration, an internal policy assistant that retrieves internal documents should not be published publicly without a separate review.
Who can change an app's access level in Dify?
Confirm the required permission in the app management docs for your version before you write a change process. Then make the decision explicit. The person who builds an app and the person who grants access should be different people where your controls require it. Enterprise custom roles and permission templates can separate those duties, but confirm the exact permissions in your release. Record who holds the permission, test it with an account that does not own the app, and review it after each upgrade, since permissions can change between releases.
How DeployOpen scopes web app access for your Dify
DeployOpen starts with a written access model before any app is published. For each Dify web app we record the intended audience, the access level chosen from the options in this topic, the identity source that will authenticate users, and the person who approves changes. That document is agreed with you in the fixed-scope statement of work, so the access decision is made once, in writing, rather than discovered during a go-live review. We also confirm which Dify edition your organization is running, because the single-workspace Community edition and the Enterprise edition differ in SSO and multi-workspace support, and that difference shapes what the model can promise.
Next, we map each app to an audience and a level, then configure and test the result with your identity owners. Testing covers the cases that usually fail: a member who is in the right group but not the right workspace, an external user who should reach one app and nothing else, and a leaver whose access should end at the identity provider. Where the deployment uses the Enterprise SSO scopes for workspace and web app sign-in, we verify each scope separately. We document the final mapping, the test results and the steps your team needs to repeat them. DeployOpen prepares this evidence for your own review and for any independent assessor you engage, but it does not issue audit reports or certifications.
Access needs change after launch as teams reorganize and new apps appear. DeployOpen can keep the model current under a retainer, covering review of new apps against the agreed levels, regression checks after Dify upgrades, and updates to the documentation. Ask any partner, including us, to confirm in writing who in your organization may approve a change to a public or external-user app, how changes are logged, and how a rollback is performed.
