Dify Enterprise SSO with Microsoft Entra ID

Entra ID restricts its sign-in pages from being rendered inside a frame on another site, a control that protects users against clickjacking and credential phishing through embedded pages. When a Dify web app is placed in an iframe on another product's page, the browser attempts to load the Entra login screen inside that frame, and the sign-in fails or shows an error instead of the login form. The exact response headers and frame rules Entra applies can change, so confirm the current behavior with Microsoft's documentation or a test tenant before you commit the design. The restriction applies to the identity provider's pages, not to the Dify app's own pages.

The embedded app loads, but any request that needs a Dify SSO sign-in redirect to Entra fails inside the frame. Users see a blank or error panel where the chat or workflow should be, and support teams often read this as a Dify fault. The failure appears only after the session expires or when a user has no existing Entra session in that browser, so it can pass a quick test by a signed-in tester. Check the embedding flow with a fresh browser profile and with an expired session before launch.

Usually not without changing how sign-in happens. Teams normally choose one of three options and evaluate each against their product and user base:

Opening the app in a new window or tab is the simplest option because the Entra sign-in runs at the top level of the browser, where it is permitted. The trade-offs are a visible context switch for users, a need to pass the user's context to the app if it should be personalized, and a separate browser session that must be handled carefully on shared devices. Confirm with your product owners whether users can accept leaving the host page, and test the return path after sign-in.

A top-level redirect moves the whole browser tab to the Dify sign-in flow, then returns the user to the host page or the app. It keeps the user in one tab, but the host product must handle the redirect cleanly, preserve any unsaved state, and return the user to the right place after Entra authenticates. Engineers should test the callback URLs for each Dify scope, since workspace and web app access use separate SSO scopes. Plan for the case where the user's Entra session has expired mid-task.

A different sign-in method fits embedded use when the audience is external or when embedding needs to be seamless and the frame restriction cannot be worked around in the host product. Options to evaluate include a separate identity provider configured for web app access, or a token-based handoff from the host product, which must be designed with your security team. Dify's Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2 protocols, so confirm which methods your Dify Enterprise edition supports for each scope before choosing. Keep staff sign-in on Entra for workspace access where possible.

Your team can handle this if it already runs Entra and Dify, has an owner for both the host product and the Dify app, and can test the embedded flow across browsers. A partner is useful when the choice of embedding pattern affects product architecture, security review or several identity providers at once. Most DeployOpen engagements are fixed-scope, with the embedding options, deliverables and timeline agreed in writing before work starts. The cost depends on how many embedding paths and identity scopes are in scope.

Ask how the proposed approach handles Entra's frame restrictions in current browsers, which Dify SSO scopes each step uses, and how the callback and return paths are tested. Ask who owns the host product changes, how session expiry and shared devices are handled, and what happens when Entra behavior changes. Request a written scope listing the embedding option chosen, the test cases, and who confirms the current Microsoft behavior before launch.

The self-hosted Enterprise edition is custom priced, so there is no published license price for SSO. The Dify pricing page lists SSO as one of the features that Enterprise adds to the free Community edition, which is limited to a single workspace. Ask for a quote that separates the cost components: the Dify Enterprise license, the infrastructure (the Enterprise resources checklist requires Kubernetes, PostgreSQL, Redis, a Qdrant vector database and object storage), your Microsoft Entra licensing under your existing agreement, and the implementation work. Licensing and infrastructure recur, while configuration and testing are usually one-time.

No fixed duration can be stated from the supplied facts, and the time depends mostly on identity review and testing. Your identity team must confirm which Entra app registration, claims and group mappings match your policy, and each Dify SSO scope (workspace access and web app access) needs its own test pass. Time also goes to change approvals, test users and any embedded apps that need extra checks. A fixed-scope engagement is agreed in writing before work starts, so ask for the timeline in that written scope, with each review gate and who signs it off.

Effort rises with the number of SSO scopes, the number of Entra groups that map to Dify roles, and the number of embedded web apps. The Dify SSO documentation separates workspace access from web app access, so each scope needs its own configuration and test. Embedded apps add work because Entra sign-in pages can refuse to render inside a frame. Other drivers include external users who sign in through a separate identity provider, the number of environments (for example staging and production), and whether the deployment runs on the Enterprise Kubernetes layout. Fewer scopes, a short group list and one environment keep effort small.

Three roles are needed, plus a named sign-off owner. First, an Entra administrator who can register the enterprise application, set claims and manage groups. Second, a Dify administrator with access to the Enterprise console to enter the SSO settings and change them later. Third, a test tenant or a test group of users, so sign-in can be verified without disrupting production users. You also need the public URLs and TLS certificates for the Dify instance, and a change window for go-live. Confirm with your security team who holds the Entra administrator rights before work starts.

An internal team can do it if it already has Entra administration skills and access to Dify Enterprise, and the Dify SSO documentation covers the supported protocols (OpenID Connect, SAML and OAuth2). The risk lies in the details: claim mapping errors, missing test coverage for each scope, and embedded apps that fail under Entra's frame rules. Changing the SECRET_KEY after deployment logs out all users, so plan any change carefully. A partner works from a written scope and deliverables. Ask either option for a test plan, a rollback path and a named owner for each scope.

SSO and SCIM solve different problems. SSO controls sign-in, while SCIM provisioning creates, updates and deactivates users and group memberships in Dify from your identity provider. Without SCIM, accounts and group membership must be maintained by hand, and a leaver can keep access until someone removes the account. Whether you need SCIM depends on your joiner, mover and leaver process and on how many users and groups you manage. Confirm with Dify whether SCIM is included in your Enterprise agreement, and plan it as a separate step with its own testing.

Entra restricts its sign-in pages from rendering inside an iframe, a framing restriction that protects users from clickjacking attacks. When an embedded Dify web app starts a sign-in inside a frame, the Entra page can fail to load, so the user never reaches the login form. Plan for this by opening sign-in in a top-level window or redirecting the user, and test every embedded app on the production URL. Confirm the current Entra framing behavior in Microsoft's documentation before you finalize the design, because the rules can change.