Dify SSO and identity integration guide

Dify SSO and identity integration starts with the edition you run

An AI platform team that needs staff to sign in through the corporate identity provider, rather than with local Dify accounts, has to start by checking which edition it is running. SSO depends on the edition. The self-hosted Community edition and Enterprise SSO are different starting points, and a design that assumes one will not carry over to the other. Dify is an LLM application development platform for building workflows, RAG pipelines and agents, and it is released under the Dify Open Source License. The Community edition is free to self-host but limited to a single workspace. The Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support.

Enterprise SSO is documented with OpenID Connect, SAML and OAuth2 protocols, with identity providers such as Microsoft Entra ID and Okta. Before choosing a protocol, confirm with the vendor which identity providers are supported for your edition and version, and whether group or role claims can be mapped to Dify roles. Ask for that mapping in writing as part of the scope. Do not assume that a protocol listed in the documentation is available on the Community edition, and do not assume a sign-in option you saw in a later release is present on the version you plan to deploy.

SSO in Dify has two scopes that must be designed separately: workspace access, which controls who can sign in to the Dify console and work in a workspace, and web app access, which controls who can open published apps. A team that secures only the console may leave published apps reachable under a different rule, or the reverse. List every entry point, decide which population may use each one, and test both paths with a user who should be denied. The SECRET_KEY setting also needs a plan. Dify uses it to sign session cookies and JWTs and to encrypt OAuth credentials, and changing it after deployment logs out all users. Generate it once, store it in your secrets manager, and make rotation a planned change window with a communication step.

Identity configuration must match in three places: the identity provider application (redirect URIs, client settings and claims), the Dify console settings, and the reverse proxy in front of Dify, which must forward the host, scheme and headers that the callback URLs depend on. A mismatch in any one of them usually shows up as a redirect loop or a login that succeeds and then fails, so write down the expected values for each component before configuring anything. Session lifetime also depends on the edition and version. Confirm the exact sign-in options available on Community and the session duration settings in the current environment variable reference for your release before you commit to a design.

Which Dify components carry identity

Identity in a self-hosted Dify deployment is spread across several services, a few secrets and one enterprise-only layer. Knowing which piece handles sign-in, session state and outbound identity lookups tells you where to test, where to restrict access and where a misconfiguration would show up first.

The api and web services

In the Docker Compose stack, the api service handles authentication requests and issues the session state the web console relies on, while the web service serves the browser front end. Both must agree on the public URL the users reach, because redirect and callback addresses for your identity provider are built from that URL. Confirm the external base URLs in your environment file match the callback URLs registered with the IdP before testing sign-in.

Nginx as the entry point

Nginx receives browser traffic and routes requests to the web and api services, so it is the place where TLS terminates and where forwarded headers are set. If Nginx sits behind a load balancer or reverse proxy, the protocol and host headers it passes on determine whether generated redirect URLs and secure cookies behave correctly. Ask your platform team which component terminates TLS and confirm that session cookies are marked secure end to end.

Redis and PostgreSQL state

PostgreSQL is the default metadata database, holding accounts, workspaces, roles and the configuration that links users to apps. Redis supports caching and transient task state in the stack. Account and role records live in the database, so a restore of PostgreSQL without the matching secret key can leave stored credentials unreadable. Include both in backup scope and confirm which metadata database you run before planning restores.

SECRET_KEY for cookies and credentials

The SECRET_KEY environment variable signs session cookies and JWTs and encrypts OAuth credentials stored by the platform. Changing it after deployment logs out every user, and credentials encrypted under the old value depend on the key being restored with the data. Generate it once, store it in your secrets manager, and document who may rotate it. Treat any rotation as a planned change with a sign-in outage window.

Enterprise SSO layer

Single sign-on with OpenID Connect, SAML or OAuth2 is part of Dify Enterprise, not the Community Docker Compose edition. The documented identity providers include Microsoft Entra ID, Okta and GitHub. Confirm with the vendor which edition, protocol and provider combinations your license covers before designing around them, since the Community edition is limited to a single workspace and does not include this layer.

Workspace and web app SSO scopes

Dify Enterprise documents two separate SSO scopes: one governs access to the workspace where builders create and manage apps, and the other governs access to published web apps used by end users. They should not be assumed to share the same policy. Map which groups need builder access, which need only end-user access to a published app, and test each scope with separate accounts.

SSRF proxy and private IdP endpoints

The SSRF proxy routes outbound requests and blocks internal and private IP ranges. If your IdP metadata document, OIDC discovery endpoint or JWKS URL is hosted on a private network, the platform may be unable to fetch it through the default settings. Confirm with your Dify contact how the proxy allowlist handles those addresses, and test sign-in from a clean session after any change.

Which SSO model fits your Dify rollout

This table compares the sign-in edition, protocol, identity provider, access scope and session choices for a self-hosted Dify rollout. Read each row for when the option fits and what it asks of your team, then confirm the items marked for checking against the current SSO documentation before you commit. Most of the operational cost comes from IdP app registration, group mapping and who maintains each setting.

Option	Operational cost	When it fits	Who owns the IdP side
Community local sign-in	No IdP link to build. Accounts, offboarding and password handling stay inside Dify. Confirm current local sign-in features in the docs.	A single workspace with a small, known user list and no requirement for central sign-in.	Not applicable. Dify admins manage accounts directly.
Enterprise SSO (custom quote)	Custom-priced license per the pricing page. Ask the quote to cover IdP app setup, group mapping and support after go-live.	Multiple workspaces, or a policy that requires central sign-in and offboarding through your IdP.	IdP team registers the app; Dify admins map roles and test.
OpenID Connect	App registration, redirect URI and client secret on the IdP side. Secret expiry needs a renewal calendar. Confirm required fields in the SSO docs.	Entra ID or Okta tenants where OIDC is the standard for enterprise apps.	IdP team owns the registration, secret and redirect URI.
SAML	Metadata exchange, attribute and group claim mapping, and signing certificate renewal. Confirm supported bindings and attributes.	IdP teams that standardize on SAML for enterprise applications.	IdP team owns the SAML app and certificate lifecycle.
OAuth2	Client credentials and provider-specific scopes. Confirm which providers and claims your edition supports before design.	Providers where your edition documents an OAuth2 flow and your IdP team cannot offer OIDC or SAML.	Provider admins own the OAuth app; Dify admins own the credentials.
Entra ID or Okta as provider	Group claims or app role assignments drive role mapping. Each group change needs a test pass in Dify. Confirm claim names.	Microsoft-centric or Okta-centric tenants where groups already govern application access.	Entra or Okta admins own groups, assignments and claim configuration.
GitHub as provider	Access follows GitHub organization and team membership. Mapping to Dify roles needs the same testing as other providers. Confirm supported org fields.	Developer-facing teams whose access already runs through GitHub organizations.	GitHub organization admins own membership and offboarding.
Scope: workspace, web app or both	Workspace SSO controls console access; web app SSO controls end-user access to published apps. Both doubles the mapping and test effort.	Workspace scope for builders; web app scope for end users; both when the same people need each.	IdP team agrees group ownership for each scope with Dify owners.
Session: long-lived or IdP reauthentication	Shorter sessions mean more IdP sign-ins. Confirm session lifetime settings. Changing SECRET_KEY after deploy logs out all users, so plan rotation.	Long-lived suits low-risk internal tools; reauthentication suits regulated or shared workstations.	IdP team sets the session policy; Dify owners confirm the lifetime setting.

How to build Dify SSO step by step

This sequence takes a self-hosted Dify from a plain install to single sign-on for workspace users and web app users, with a check at each step. Each check confirms something observable, such as a successful login, a claim in the console or a denied user, before the next step starts.

Confirm edition and license scope
Before any configuration, confirm in writing that the deployment is the Enterprise edition, because SSO and multiple workspaces are not part of the free self-hosted Community edition, which is limited to a single workspace. Review the Dify Open Source License conditions on multi-tenant use and logo removal with your legal or procurement team, and make sure the planned number of workspaces and the identity features match the agreed scope. This step is done when the edition, the workspace count and the SSO requirement appear in the signed scope document and the Enterprise console shows the SSO settings to an administrator.
Set public URL and TLS on the entry point
Decide the public hostname that users and the identity provider will use, then publish it through your reverse proxy or load balancer with a valid TLS certificate. Set the public URL values in the environment configuration so that generated redirect URIs use this hostname and the HTTPS scheme. Keep the hostname fixed from this point on, because the redirect URI registered with the identity provider must match it exactly. The check is that the console address loads over HTTPS with a certificate your browsers trust, and that the redirect URI shown in the configuration matches the registered hostname character for character.
Generate and store SECRET_KEY before first login
Generate a unique SECRET_KEY and store it in your secrets manager before the first administrator signs in. Dify uses this value to sign session cookies and JWTs and to encrypt OAuth credentials, so it must be set in the deployment configuration rather than left at a placeholder. Record who holds the value and where the backup copy lives, because changing it after deployment logs out all users and can make stored OAuth credentials unreadable. The check is that the value is present in the running configuration, the administrator can sign in, and the service still accepts that session after a restart.
Register Dify in Entra ID or Okta
In Microsoft Entra ID or Okta, create an application registration for Dify using the protocol your edition supports, OpenID Connect, SAML or OAuth2, and the identity provider's own setup steps. Enter the redirect URI built from the public hostname, request the scopes Dify needs for sign-in, and configure the claims that carry the user's email address, name and group membership. Assign a test group to the application so that only intended users can sign in. The check is a token or assertion inspection for the pilot account showing the expected subject, email and group claims, and a sign-in attempt by an account outside the assigned group being refused by the identity provider.
Map IdP groups to workspace roles
Decide which identity provider groups correspond to which Dify workspace roles, and document the mapping as a table that the identity team and the Dify administrators both approve. Keep the number of groups small enough that a reviewer can read the table in one sitting, and decide what happens to a user who belongs to no mapped group. Apply the mapping in the Enterprise console. The check is that a pilot user in a mapped group lands in the expected workspace with the expected role, that the group or role appears against the user in the console, and that a user with no mapped group does not receive access to any workspace.
Configure the protocol and test with one pilot user
In the Enterprise console, enter the identity provider details from the registration step, including the issuer or metadata location, client identifiers and the attribute names for email and groups, then save the protocol configuration. Sign in with one pilot user from a clean browser session, not from an existing administrator session. Compare the user record created in Dify against the identity provider record to confirm the email address and group membership match. The check is a successful login, a user entry in the console with the expected attributes, and a failed login for an account that the identity provider has not assigned to the application.
Configure web app access and test with an external user
Web app access is a separate SSO scope from workspace access, so configure it on its own rather than assuming the workspace setup covers it. Choose which published apps external users may open, and set the identity provider policy for that group of users so they are not granted console access. Publish a test app, then sign in as an external user who has no workspace role. The check is that the external user reaches the published app through the web app login, cannot open the console or other workspaces, and that an unpublished app returns an access error for the same user.
Rehearse session expiry, logout and deprovisioning
Run a scripted rehearsal with the pilot and external test accounts before anyone else is onboarded. Confirm the session length configured for Dify ends the session at the expected time, that logout from Dify also ends the session in the browser, and that a user removed from the identity provider group is refused at the next sign-in attempt and loses workspace access in the console. Record the results with timestamps and the configuration values used, so the same rehearsal can be repeated after upgrades or SECRET_KEY changes. The check is a written rehearsal log showing each expected outcome, with any deviation assigned to an owner for correction.

What drives SSO effort and cost

This table lists the factors that change how much work Dify SSO takes and what it costs, with a way to keep each one small. Read each row as a lever: the fewer identity providers, workspaces, environments and evidence obligations you carry, the smaller the configuration, testing and support load. The main takeaway is that most cost comes from scope decisions made before build starts, so settle them in writing first.

Driver	Why it changes effort or cost	How to keep it down
Number of IdPs and protocols	Each identity provider and each protocol (OpenID Connect, SAML or OAuth2) needs its own registration, claim mapping, test sign-in and fallback plan.	Standardize on one IdP, such as Microsoft Entra ID or Okta, and one protocol for all workspaces and web apps.
Workspaces and role model	Each workspace needs its own role assignments and access checks, and multi-workspace access is an Enterprise capability.	Use a single workspace model where possible and define roles once, then map them consistently.
External users reaching web apps	Web app access for people outside the company adds a separate SSO scope, extra identity rules and more exposure to test.	Limit web app SSO to internal users first, and decide in writing whether any external audience is in scope.
Group mapping complexity	Per-user grants must be created and reviewed by hand, which grows with headcount and every role change.	Map access by IdP groups rather than per-user grants, and keep the group count small and named clearly.
Environments needing redirect URIs	Development, test and production each need registered redirect URIs and separate test sign-ins, multiplying setup and troubleshooting.	Reuse one tested configuration template across environments and change only hostnames and secrets per environment.
Compliance evidence such as access reviews	Assessors may ask for periodic access reviews, sign-in records and change history, which need a repeatable export and an owner.	Agree the evidence list at scoping, define who runs each access review, and export group membership on a fixed schedule.
Cost component: Enterprise licensing	SSO in Dify is part of the self-hosted Enterprise edition, which is custom priced, so this is a recurring commercial cost. Confirm the terms and renewal basis in writing with Dify.	Confirm in the quote which features, workspaces and support terms are included before committing to SSO scope.
Cost component: internal IdP admin time	Your identity team creates app registrations, groups, claim rules and periodic reviews, and this effort recurs after go-live.	Ask who owns each registration and group, and budget the recurring review work during scoping.
Cost component: DeployOpen implementation scope	DeployOpen is paid for the fixed-scope work agreed in writing: configuration, testing, documentation and handover. Its cost follows the written scope, not a list price.	Ask for the quote to name the IdP, protocol, workspace count, environments and evidence deliverables explicitly.

How the SSO setup differs by deployment model

The Community edition runs as a Docker Compose stack on infrastructure you control, and local accounts are the baseline sign-in method. Before planning federated sign-in, confirm with the vendor which sign-in options the Community edition exposes for your chosen version, because federated single sign-on is documented under the Enterprise edition. If the option you need is missing, treat that as a scope decision: either accept local accounts with a documented account lifecycle, or move the requirement into an Enterprise quote.

What to check in this model:

Sign-in options: list every method the running version offers in the console and in the environment reference, not only what the docs describe.
Account lifecycle: decide how accounts are created, disabled and reviewed when someone leaves, since local accounts do not inherit directory deprovisioning.
Single workspace limit: the Community edition is limited to one workspace, so workspace-level access rules have less room to differ.
Session settings: confirm how SECRET_KEY and session behavior apply to this single node before relying on them for access control.
Edition gap: record any SSO requirement that the Community edition does not meet as an input to the edition decision.

Confirm the sign-in options and their documented limits with the vendor for the exact version you plan to run.

How to protect identity secrets and sessions in Dify

Dify's sign-in security depends on a few secrets and on controls that sit partly in Dify and partly in your identity provider. The cards below cover the keys that protect sessions and OAuth credentials, how to rotate them without surprising users, and the IdP and console settings that complete the picture.

Generate and store SECRET_KEY

SECRET_KEY signs session cookies and JWTs and encrypts stored OAuth credentials, so it is the first secret to plan. Generate a long random value with a cryptographic tool, never reuse a value from a sample file, and place it in your secrets manager rather than in a committed .env file. Confirm the minimum length and format in the Dify environment variable reference before you deploy.

Plan SECRET_KEY rotation

The environment reference states that changing SECRET_KEY after deployment logs out all users, so rotation is a scheduled change rather than a routine task. Pick a maintenance window, notify the user community, and record the rotation in your change log. Test the procedure in a staging copy first, including what happens to stored OAuth credentials, which SECRET_KEY encrypts.

Store OAuth client secrets safely

Each identity provider application gives Dify a client ID and client secret for the OpenID Connect, SAML or OAuth2 flow. Keep these secrets in your secrets manager, restrict who can read them in the IdP admin console, and set a rotation date for each one. Confirm with the identity provider how it expires or rotates client secrets and whether Dify needs a restart to pick up a new value.

Restrict IdP admin roles

Anyone who can change the Dify application in Entra ID or Okta can change group mappings, redirect URIs or assigned users, which can grant access to the console. Limit the application owner and administrator roles to a small named group, separate them from people who manage Dify day to day, and review assignments on a fixed schedule. Log and alert on changes to the Dify application object.

Enforce MFA at the identity provider

Set multi-factor authentication as a condition in the IdP's sign-in policy for the Dify application, so every route into the console passes through it. Dify's SSO flow relies on the IdP to authenticate the user, so an MFA rule in Dify would not replace one in the IdP. Test the policy with a user who has a single factor enrolled and with a sign-in from an unmanaged device.

Limit who can publish web apps

Web apps have their own SSO scope, separate from workspace access, so the question is who may make an app reachable outside the workspace. Decide which roles can change an app's access setting, document the rule, and review published apps against the owners who requested them. Confirm in the Dify app management documentation which roles can set access levels in your edition.

Keep the console behind TLS

Terminate TLS in front of the Nginx service or your load balancer, redirect plain HTTP to HTTPS, and confirm that the redirect URIs registered with the IdP use HTTPS. Session cookies and OAuth callbacks carry the protection of the session, so an unencrypted path weakens every control above. Check how cookies are marked secure in your deployment and confirm the setting in the Dify self-hosting documentation.

Protect workspace encryption keys

Workspace encryption keys can be stored locally or in Azure Key Vault, which is a related control rather than an SSO setting. If your organization already runs Key Vault, decide early whether the workspace keys follow the same access policy and rotation process as SECRET_KEY. Confirm the setup steps and key handling in the Dify environment reference before choosing a storage option.

How to test that Dify SSO works and fails safely

A Dify SSO test plan has one job: prove that people get the access their identity provider grants on sign-in and lose it when their group membership is removed. Run five cases against a named test account for each, and write down the expected result before you run it. First, a new user signs in through the IdP and lands in the workspace role mapped to their group. Second, a user removed from the IdP group loses access once the Dify session ends, so measure the session duration you configured and test at the end of that window, not only at the moment of removal. Third, a user without the right group cannot open a protected web app. Test workspace access and web app access separately, because Dify Enterprise documents them as distinct SSO scopes. Fourth, logout clears the Dify session, which you confirm by reusing the old session cookie. Fifth, a misconfigured redirect URI fails closed.

The redirect URI case needs the most care. Send a sign-in request with a deliberately wrong redirect URI and confirm that Dify refuses it, returns no token, and shows an error that names neither the client secret nor any internal path. Then search the API and web container logs for the same attempt. Look for OAuth client secrets, the SECRET_KEY value, tokens and full callback URLs with codes in them. Dify's environment reference says SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, so treat any appearance of it in a log as a finding. Confirm the log level, output destination and retention for your release in the environment variable reference, since these differ by deployment. Compare the entries with the IdP sign-in log to confirm both sides recorded the same failure.

Test a break-glass administrator path before go-live and again after any change to SSO settings. The path should let a named, small group of people reach the Dify console when the IdP or its federation metadata is unavailable. Confirm with Dify whether local login remains available when SSO is enforced in your edition and version, because this decides the whole design. Document who holds the emergency credentials, where they are stored, how access is sealed and reset, and which alert fires when the account is used. A break-glass path that has never been exercised is not a tested control, so schedule a drill, record its outcome and store the runbook next to the SSO configuration.

Rehearse SECRET_KEY rotation on a non-production copy restored from a recent backup, not on the live system. Dify's environment reference states that changing SECRET_KEY after deployment logs out all users. Measure how long your rehearsal takes, confirm which stored OAuth credentials still work after the change, and note every credential that must be re-entered. Confirm with Dify whether encrypted values can be re-encrypted in place or must be re-created, and write that answer into the runbook. Keep the rehearsal log, because it becomes the basis for the change plan and for any question an assessor asks about how keys are managed.

Record evidence as you test, not afterward. For each case, keep the test ID, date, tester, Dify version, IdP configuration export, the expected and observed result, and a screenshot or log extract with secrets and personal data redacted. Store the redaction method with the evidence. Keep the rotation and break-glass records in the same set. Evidence like this supports a compliance assessment by showing what was tested and what happened, but it does not prove compliance on its own. DeployOpen prepares systems, controls and evidence for assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.

Can we set up Dify SSO ourselves, and what does a partner change?

Can the Dify Community edition use single sign-on?

The documented path to SSO in Dify is the Enterprise edition, which the pricing page lists alongside multiple workspaces, advanced security, a commercial license and professional support. The Community edition is free, self-hosted and limited to a single workspace, and Dify's Enterprise SSO documentation is the reference for OpenID Connect, SAML and OAuth2 setups. Confirm the sign-in options in the Community release you plan to run with Dify before you design around them, since options can change between versions. Record the answer in your scope document. If the Community edition does not meet your login requirement, the decision becomes a licensing decision, and that changes the budget conversation early.

What does Dify Enterprise licensing involve for SSO?

Dify does not publish a price for the self-hosted Enterprise edition. The pricing page lists it as custom priced and says it adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Ask for a written quote that names each of those items, the number of workspaces in scope and the support level. Dify Cloud plans are listed at 590 US dollars per year for Professional and 1,590 US dollars per year for Team, according to the Dify pricing page, but those are cloud subscriptions and are not a benchmark for a self-hosted Enterprise license. Confirm which parts recur each year, such as the license term and support, and which are one-time, such as configuration and testing.

How long does a Dify SSO integration take to deliver?

The duration depends on how many identity providers you connect, how many workspaces and web apps need separate access rules, how your group model maps to Dify roles, and how much testing your users require. Each of these is a scope decision, so DeployOpen agrees the timeline in writing before work starts. A single identity provider with one workspace is usually simpler than several providers feeding multiple workspaces, and a larger test population adds time for validation and rollback planning. Ask any partner, including us, to show which of these drivers they counted in the estimate and what changes the timeline if one of them grows during the project.

What do we need to provide for a Dify SSO project?

The project needs administrator access to your identity provider, such as Microsoft Entra ID or Okta, so the application registration, claims and group settings can be configured and checked. It also needs an agreed group model that defines which users reach which workspaces and web apps, and a named test population that covers each group. You will need DNS records for the Dify hostname and a TLS certificate that your users' browsers trust, plus administrator access to the Dify deployment itself. Confirm these inputs in writing at the start, because missing access or an unclear group model is the most common reason integration work stalls.

Can our internal team set up Dify SSO without a partner?

Yes, if the team owns both the identity provider and the Dify administration and has the Enterprise license in place. The work involves registering the application with the IdP, configuring OpenID Connect, SAML or OAuth2 in Dify, mapping groups to workspace access and web app access, and testing sign-in and sign-out for each group. Plan changes carefully: according to Dify's environment reference, SECRET_KEY signs session cookies and JWTs, and changing it after deployment logs out all users. Your team should also own the rollback path and the documentation that follows the configuration. If the identity team and the Dify team are different people, agree on ownership before the first test.

What does a fixed-scope partner SSO engagement include?

A fixed-scope engagement covers the items agreed in writing before work starts, usually the identity providers and protocols in scope, the workspace and web app access rules, the group mapping, DNS and TLS setup, a test plan with named testers, cutover and rollback steps, and handover documentation. DeployOpen plans, implements, integrates, hardens and documents the work inside your own infrastructure, so the configuration and records remain yours. Scope excludes anything not listed, such as new identity providers added later. Ongoing support, upgrades and testing are available as separate retainers. Ask for the scope document to list each deliverable, the acceptance criteria and who signs off each step.

How should we test Dify SSO before cutover?

Test each identity provider, protocol and group combination separately, and test workspace access and web app access as distinct scopes, because Dify's Enterprise SSO documentation lists them separately. For each group, confirm that users who should sign in can reach the right workspace and web apps and that users outside the group are refused. Check sign-out, session expiry behavior and what happens when a user is removed from a group in the IdP. Run the test population through the full path, including DNS, TLS and any proxy in front of Dify, and keep the results as evidence. Record the rollback steps before cutover so the team can return to the previous login path if a test fails.

How DeployOpen scopes, builds and hands over Dify SSO

DeployOpen plans and builds Dify sign-in against your identity provider inside your own infrastructure, with the protocol, scope and session settings agreed in writing first. Engagements are fixed-scope, and ongoing support is available as a retainer once the integration is live.

How we scope

We confirm whether you need Community sign-in only or Enterprise SSO over OIDC, SAML or OAuth2, as Dify's SSO documentation describes.
We record which identity provider is in use, such as Microsoft Entra ID or Okta, and which users need workspace or web app access.
The written scope names the session duration, group mapping and logout behavior you require, along with the environments and accounts involved.

How we build

We configure the identity provider application, redirect URIs and claims, then wire them into Dify's environment settings in a non-production deployment first.
We set SECRET_KEY handling and cookie and session values deliberately, noting that changing SECRET_KEY after deployment logs out all users.
We test sign-in, sign-out, role mapping and denial paths for both workspace and web app SSO scopes before anything moves to production.

How we hand over

You receive a configuration record covering identity provider settings, Dify variables, protocol choices and the rationale for each one.
The runbook covers certificate or client secret rotation, how to add or remove users and groups, and how to recover if the identity provider is unavailable.
We walk your identity and platform teams through the sign-in flow and the test evidence so they can operate the integration without us.

How we support

Post go-live support can be placed on a retainer, with the response expectations written into that agreement rather than assumed.
We review identity configuration whenever you upgrade Dify, since new releases and .env variables can change authentication behavior.
We confirm with your identity provider vendor any feature we have not verified in your tenant before we rely on it in a change.