Langfuse SSO and identity integration guide

How Langfuse SSO works in a self-hosted deployment

Langfuse supports SSO through Auth.js providers, including Okta, Entra ID, Keycloak and generic OIDC, and it can enforce SSO for specific email domains. For a security or platform lead who must put LLM traces and prompts behind corporate sign-in before wider rollout, this is a configuration task on the Langfuse Web container, not a separate project. In a self-hosted deployment, Langfuse Web handles the sign-in flow. It redirects the user to the identity provider, which authenticates them, and then receives the response at a callback URL on your Langfuse domain before creating the session. Langfuse Worker takes no part in sign-in, so changes to the login path affect only the web tier.

Three teams own different steps. The identity team, which usually runs Okta, Entra ID or Keycloak, registers Langfuse as an application, defines the allowed redirect targets and decides which groups or users may sign in. The platform team sets the environment variables for the chosen provider, stores the client secret in the same secrets manager used elsewhere in the stack, and redeploys the web containers. The security lead owns the decisions on whether password sign-in is disabled and which email domains are forced onto SSO, then verifies both. Confirm the exact variable names and provider fields against the authentication documentation for your Langfuse version before the change window, because these details change between releases.

Three things make this harder than it looks. First, redirect URIs must match exactly. The value registered at the identity provider has to equal the callback URL Langfuse uses, including scheme, host, port and path. A change to the public domain, a reverse proxy or a new load balancer can break sign-in without any code change. Second, admin access must survive a misconfiguration. Before you enforce SSO or disable password sign-in, keep a tested recovery path, such as a break-glass account or a documented way to re-enable credentials, and rehearse it on a non-production instance. Third, some user-management features need an Enterprise license key. SCIM provisioning, project-level roles and the org management API are gated, so an identity team that expects automatic deprovisioning through SCIM will not find it on the open source plan.

Before go-live, run a short test matrix. Sign in with a user from each enforced domain, confirm that a user from an unlisted domain is routed as intended, confirm that an account disabled at the identity provider cannot start a new session, and confirm that the recovery path works. Record who approved each setting. Ask the identity team to confirm group claims and session lifetimes, since offboarding behavior depends on both sides. Keep the redirect URIs documented per environment so that a staging change does not overwrite production settings.

Choosing an identity path: built-in providers, generic OIDC or Enterprise features

This table compares the identity choices for self-hosted Langfuse: a named provider, generic OIDC, email-domain enforcement, and open source versus the Enterprise license key. Read each row for when the option fits and what your team keeps running after go-live, such as app registrations, claim mapping, key renewal and break-glass access.

Decision	Option A	Option B	When to choose it
Provider type	Named provider (Okta, Entra ID, Keycloak and others listed in Langfuse docs)	Generic OIDC for an identity provider not in the named list	Named provider when your IdP is on the list. Generic OIDC when it is not, but expect to map claims and endpoints yourself.
App registration ownership	Named provider setup follows Langfuse's documented steps for that IdP	Your team defines client ID, secret, redirect URL and scopes for each environment	Assign an owner for the registration in each environment, and track who renews the client secret before it expires.
Claim mapping upkeep	Lower effort when the IdP's default claims match what Langfuse reads	Higher effort: you map email, name and group claims and retest after IdP changes	Choose generic OIDC only if someone will review claim mappings after every IdP tenant or policy change.
Email domain enforcement	SSO enforced for listed email domains so those users cannot use password sign-in	Password and SSO allowed together for the same users	Enforce SSO for regulated groups. Confirm with your IdP team how users on domains outside the policy will sign in.
Password sign-up	Disable password sign-in so SSO is the only route	Keep password sign-in for break-glass or non-SSO accounts	Keep at least one tested admin path that works if the IdP is down, and document who holds it.
Break-glass admin access	Local admin account kept under strict control and tested on a schedule	Relies on the IdP being available, with no local fallback	Test the fallback after every change to SSO settings, before enforcing SSO on production.
Open source only	Core features and APIs are available under the MIT license, with no key	Project-level roles and access controls depend on the Enterprise scope	Stay open source if one shared role level across the instance meets your access model.
Enterprise license key	Adds project-level RBAC, the org management API with SCIM, and audit logs (per Langfuse license key docs)	Needs a key issued under the separate enterprise license, plus renewal and key handling in your deployment	Choose it when you need per-project roles, SCIM provisioning or audit evidence. Confirm the current scope and renewal terms with Langfuse before you decide.

Configuring Langfuse SSO with your identity provider

This sequence connects a self-hosted Langfuse instance to one OIDC identity provider so users sign in with their corporate accounts. Each step closes with a check you can record, and the sequence finishes only after an existing admin account has signed in successfully.

Confirm the version and license key requirement
The platform lead records the deployed Langfuse version and reads the authentication and SSO documentation for that exact version before any setting changes. Compare the planned setup against the license key documentation, which lists the features that need an Enterprise key, and confirm with Langfuse whether sign-in through your chosen provider is covered by your edition. Record the version, the provider and the licensing answer in the change ticket. The step is done when the team signs off on that written statement.
Register Langfuse as an application in the provider
An administrator in the identity provider creates a web application for Langfuse as a confidential OIDC client, using the grant types and scopes the Langfuse documentation specifies for the chosen provider. Store the client secret in your secrets manager at creation time, not in a chat, ticket or shared document. Assign a pilot group to the application. The step is done when the application appears in the provider console, a pilot user is assigned, and the provider's own sign-in test completes without error.
Set the callback URL to the public address
The provider application needs a redirect (callback) URL that matches the public address users reach Langfuse on. The scheme, host name and callback path must match what the Langfuse documentation gives for the deployed version, character for character. A trailing slash or an internal host name is a common cause of redirect errors. Confirm the public address with the team that owns DNS and the load balancer. The step is done when the saved callback URL matches the documented path and the provider no longer reports a redirect mismatch when tested from a browser.
Set client ID, secret and issuer in Langfuse
The deployment engineer adds the provider's client ID, client secret and issuer values to the Langfuse web container environment, using the exact variable names given in the authentication documentation for the deployed version. Inject the secret from your secrets store at runtime so it does not appear in container images, values files or plain-text manifests. Use the issuer URL published by the provider's discovery document. The step is done when the rendered deployment shows the three values as expected and no secret appears in pod descriptions or logs.
Restart Langfuse and check startup logs
The platform team rolls out the web and worker containers so both pick up the new environment. Changes to authentication settings affect the web container, but restarting the worker keeps both processes on the same configuration. Watch the startup logs for authentication configuration errors, and confirm the sign-in page shows the provider option. The step is done when both containers report healthy, the logs contain no configuration errors for the provider, and the login page offers the provider sign-in button.
Test sign-in with an existing admin account
An administrator who already has a working Langfuse admin account signs in through the provider from a private browser session. Confirm that the sign-in lands in the expected organization and that the email address and display name on the Langfuse user match the provider record. Review the provider's sign-in log for the test, looking for a success event without repeated prompts or errors. Keep password sign-in enabled at this stage so a working break-glass path remains. The step is done when the admin signs in, the attributes match, and the provider log is clean.
Enforce SSO for email domains after verification
Only after the admin test passes, the platform lead enables SSO enforcement for the corporate email domains and disables password sign-up, using the setting names given in the authentication documentation for the deployed version. Document and test the break-glass procedure before saving the change, so an administrator can still recover access if the provider is unavailable. Create a new test user from a covered domain and confirm the account is provisioned with the correct email and name. The step is done when a new user signs in through the provider and the provider log shows no unexpected events.

Enforcing SSO by email domain and closing password sign-up

The order of these changes decides whether anyone gets locked out. Enable the identity provider first, then verify a full sign-in end to end, including the callback back into Langfuse and the access your test user receives. Enforce SSO by email domain second, once that test passes. Disable password sign-in last, after you have confirmed that every account you need can sign in through the provider. Each step removes a way in, so an error at the wrong step can leave the instance with no working login path. Treat the sequence as a change runbook with a named owner and a checkpoint after each step, and avoid combining the three changes into one deployment.

Domain enforcement changes sign-in for anyone whose email address matches a configured domain. For those users, Langfuse sends the sign-in to the identity provider, and the local password form is no longer their route in. Disabling password sign-in goes further, because it removes the local login path for the whole instance, including accounts created before SSO existed. Before you disable it, list every account that does not belong to an enforced domain, and identify any automation or break-glass account that depends on a password. Confirm the exact settings and how they interact in the Langfuse authentication and SSO documentation for your version, since the interaction between domain rules and the password toggle is the detail most likely to differ from what your team assumes.

Users with addresses outside the enforced domains may still need a different path. Contractors, partner staff, or a personal address used by an early user can fall outside the domain rule and may be unable to sign in once passwords are closed. Decide before enforcement which groups will be invited through an allowed provider, which will keep a separate path, and which will lose access. Record the decision for each group, and test a sign-in from a representative account in each group before the change window. The answer should come from your access policy and your identity provider's configuration, and it should be checked against how the tool actually behaves in your version.

Keep a documented recovery path for the instance administrator. Record who can change the authentication configuration, where those settings live in your deployment (environment variables, Helm values or a secrets store), and how an administrator regains access if the identity provider is down or misconfigured. Confirm what an administrator can still do with an enforced domain and passwords disabled, and whether a separate emergency account is supported in your version. Rehearse the recovery procedure in a non-production environment before you rely on it, and store it with the deployment runbook. Review it after each provider change, such as a rotated client secret, a new realm or tenant, or a change to the redirect URL.

How SSO setup differs in Docker Compose, Kubernetes and air-gapped networks

Docker Compose on a single VM is the documented route for testing Langfuse. It runs the web and worker containers beside PostgreSQL, ClickHouse, Redis or Valkey and blob storage on one host, so the identity provider setup is usually the first thing to prove before production identity controls are designed. Docker Compose is documented for testing and does not provide high availability.

Callback URL and TLS: The callback URL points at the single host name assigned to the VM. Test setups often use a self-signed certificate or plain HTTP, which many identity providers will refuse for redirect URIs, so confirm what your provider accepts for test applications.
Secrets: The client ID and secret usually sit in the Compose environment file on the VM. Restrict file permissions and keep the file out of version control, because the default layout does not include a secrets manager.
Reachability: The web container needs outbound HTTPS to the identity provider to read discovery metadata and exchange tokens. Check the VM's egress rules and any proxy settings.
Endpoint split: There is one web deployment, so all sign-in traffic reaches the same container. The ingestion and UI split does not apply at this scale.

Before moving on, check that the callback, certificate and egress path work end to end, then record each setting so the production build can reuse the same identity configuration.

What drives SSO integration effort

This table lists the factors that change how much work a Langfuse SSO integration takes, what raises each one, and how to keep it down. Read each row against your own identity estate, since the number of providers, environments and admin lead times usually matter more than the Langfuse configuration itself. Items that need an Enterprise license key are flagged so that key decisions are made before the build starts.

Driver	What raises effort	How to reduce it
Identity providers and tenants	Several IdPs or tenants (for example, separate Entra ID tenants per business unit), each with its own OIDC client, redirect URI and claim behavior	Confirm which IdP is authoritative for each user population before build, and avoid a second IdP unless a regulated group needs one
Environments (test, staging, production)	Each environment needs its own OIDC client, callback URL, secrets and test accounts, and drift between them causes late failures	Use one shared test IdP app and document one configuration template that is promoted unchanged to staging and production
IdP admin access and change lead times	The client admin, claim mapping and redirect URI changes sit with a separate identity team that may have approval queues	Name the IdP administrator and approver in the plan, request the OIDC client and test users early, and batch change requests
Group and role claim mapping	Langfuse roles depend on the groups or claims your IdP emits, and inconsistent group names across providers multiply testing	Agree one reviewed claim schema covering group names, the email claim and any role mapping before configuring the first provider
Email domains to enforce	Each domain that must be forced through SSO needs its own check, and users with existing password accounts on those domains need a migration path	List every domain and its owner, confirm which accounts already exist, and test sign-in for each domain before disabling password sign-in
SCIM provisioning and project-level roles	SCIM and project-level RBAC need an Enterprise license key and a provisioning source, and they add user lifecycle testing (joiners, movers, leavers)	Decide early whether you need the Enterprise key, confirm the license terms with Langfuse, and scope SCIM only to the groups that must be provisioned
Compliance evidence for access control	Assessors may ask for proof of enforced SSO, access reviews, role assignments and change history, which must be captured during the build	Define the evidence list at the start (configuration records, test results, access review exports) and confirm with your assessor what they will accept

Hardening sign-in: secrets, callbacks, admin access and session scope

Single sign-on for self-hosted Langfuse is only as strong as the settings around it. The cards below cover the places where a sign-in configuration most often drifts: credentials, redirect targets, who can change authentication, recovery access, trusted domains and the audit trail.

Keep the OIDC client secret out of code and images

The client secret your identity provider issues for Langfuse should be injected at runtime from a secrets manager or orchestrator secret, not written into Docker Compose files, Helm values committed to Git or baked into container images. Check the repository history and image layers for the value, and rotate it if it was ever exposed. Confirm with your platform team which secret store the deployment will read from and who can read it.

Restrict redirect URIs to exact HTTPS callbacks

In the identity provider, register only the exact callback URL that Langfuse uses for your public base URL, served over HTTPS. Avoid wildcards, localhost entries left from testing and multiple hostnames that point at the same deployment. A mismatch between the configured external URL in Langfuse and the registered callback is a common cause of sign-in failures, so verify both values together after any hostname change.

Limit who can change authentication settings

Changes to SSO providers, enforced domains and password sign-in are made through environment configuration and redeployment, so control access to the deployment pipeline, the environment variables and the Kubernetes namespace or VM that hosts them. Keep these permissions separate from general application administration. Ask your team to list every person and service account that can alter authentication configuration and review that list on a fixed schedule.

Keep a named break-glass administrator

Before enforcing SSO for all users, decide who keeps a working local path into the instance if the identity provider is unavailable or misconfigured. Name that person, record where the recovery credentials are stored, and document the steps to re-enable password sign-in or correct the provider settings. Test the procedure in a non-production environment. Without this, a bad redirect URI or an expired client secret can lock every administrator out at once.

Review trusted email domains

When Langfuse enforces SSO for specific email domains, every domain on that list grants access through your identity provider. Compare the list against the domains your organization actually owns, remove contractor or legacy domains that no longer apply, and confirm that the identity provider only issues accounts for those domains. Repeat this review whenever a business unit, acquisition or vendor relationship changes.

Log sign-in and admin changes for review

Enable the audit trail that your Langfuse edition provides for administrative actions, and forward sign-in events from the identity provider to your central logging. Confirm with Langfuse whether audit logs require the Enterprise license key in your deployment before you rely on them for review. Define who reads these logs, how often, and which events trigger investigation, such as new SSO providers, changed domains or repeated failed sign-ins.

How to test that SSO works and fails safely

Test SSO before anyone depends on it, and test the failure paths as carefully as the success path. The goal is to show that users from your enforced email domain can sign in through the identity provider, that everything else is refused or handled exactly as configured, and that a broken provider setting cannot lock every administrator out of the Langfuse instance. Run these cases in a staging instance built from the same configuration you plan to promote, and write down the expected result for each case before you run it. Start with the positive cases. Sign in with a test user from the enforced domain through the provider you configured, whether that is Okta, Entra ID, Keycloak or generic OIDC, and confirm that the account is created or matched in Langfuse with the expected name and email. Then check the negative cases that matter most for regulated teams. Password sign-in should be refused once it is disabled, including on the sign-in page and through any direct request to the credentials path. A user from a different email domain should be handled as your configuration says, either refused or admitted through an allowed route. Document which outcome you chose and prove it with a test record, not an assumption. Next, test offboarding. Disable or remove a test user in the identity provider and confirm that the user's existing Langfuse session stops working and that a fresh sign-in attempt fails. Session lifetime matters here, so record how long a previously issued session stayed valid after the change. Then deliberately enter a wrong client secret in a copy of the configuration and confirm that sign-in fails cleanly. The break-glass administrator account must still be able to sign in through its own route. If you cannot demonstrate that, fix the recovery path before go-live. The Enterprise-only features need their own check. Confirm that the open source instance runs the core SSO and domain enforcement behavior without a license key, and that features such as project-level RBAC roles, audit logs and SCIM provisioning are either absent or clearly unavailable there. On an instance with a valid key, confirm that those features appear and behave as your contract describes. Confirm the exact feature list with Langfuse's license key documentation and your sales contact, because the list can change between releases. Keep the evidence. Store the test plan with expected results, the dated test records showing actual results, screenshots or logs of each denied and allowed sign-in, and the configuration diffs between staging and production. Include the version of Langfuse you tested, because SSO behavior can change across upgrades. Auditors and your own security team will ask how you know the controls work, and a record made at test time answers that better than a later description.

What to monitor, back up and document after SSO goes live

Go-live starts the SSO lifecycle rather than ending it. The six areas below cover what keeps sign-in working over time: watching for failures and expiring credentials, controlling changes, re-testing after upgrades, managing access, and keeping enough written detail for someone else to recover the setup.

Watch sign-in failures and expiry dates

Track failed sign-ins and redirect errors at the identity provider and in Langfuse logs, so breakage is noticed before users report it. Record the expiry date of every client secret and signing certificate the integration uses, and set reminders well ahead of those dates. Expired credentials often cause sudden lockouts after SSO has been stable for months, so check both sides of the integration.

Put configuration and secrets under change control

Keep the OIDC client settings, email domain enforcement rules and environment variables in version-controlled deployment definitions that your team can review. Store the client secret in a secrets manager and limit who can read or rotate it. Changes to redirect URIs, allowed domains or password sign-in settings should follow the same review and approval path as other production changes.

Re-test SSO after every upgrade

Updates within a major version apply database migrations automatically at startup, so a routine patch can change behavior your sign-in depends on. Repeat a scripted test of login, domain enforcement, password sign-in and session expiry after each upgrade. Major upgrades follow dedicated guides and need their own test cycle. Confirm upgrade and SDK versions against the upgrade guide for the target release. At time of writing, the latest release on the Langfuse releases page is v4.63.0, published October 16, 2026.

Review user access and deprovisioning

Review who holds Langfuse roles at regular intervals, especially project-level roles, which need an Enterprise license key. Write down what happens when someone leaves: whether removing them at the identity provider also ends their Langfuse session, and whether any local or API accounts remain. Confirm SCIM provisioning availability for your edition, since SCIM and the organization management API also require an Enterprise key.

Keep a recovery runbook

Document how to restore sign-in if the identity provider is unavailable, a secret has expired or a misconfiguration locks out administrators. Keep a break-glass path, such as a local administrator account stored under separate control, and confirm it works before you need it. Include who can approve emergency changes, where database and blob storage backups are kept, and the order in which services should be restored.

Document the identity provider configuration

Record the provider type, tenant or realm, redirect URI, scopes and claims Langfuse reads, the email domains it enforces, and the group or role mappings used for access. Note who owns the application registration at the provider and how to request changes. This record lets a new engineer or auditor trace how sign-in is wired without reconstructing it from the admin consoles.

Questions buyers ask before bringing in help with Langfuse SSO

Can the open source version of Langfuse use SSO?

Yes. The MIT-licensed open source version of self-hosted Langfuse supports SSO through the Auth.js providers it documents, including Google, GitHub, Microsoft Entra ID, Okta, Auth0, Keycloak, OneLogin, JumpCloud, Authentik and AWS Cognito, and through generic OIDC for other identity providers. Langfuse also documents options to disable password sign-in and to enforce SSO for specific email domains. Confirm the exact provider list and settings for your Langfuse version in the authentication and SSO documentation before you design the integration, because provider support can change between releases.

Which Langfuse SSO features need an Enterprise license key?

Core SSO sign-in does not need a key. Features that do need an Enterprise license key include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the organization management API with SCIM provisioning, and the instance management API. The license key documentation is the list to check, since it is the reference for which features are gated. If your plan depends on SCIM or project-level roles, ask Langfuse to confirm current availability for the version you will run, and get that confirmation in writing before scoping the work.

How long does a Langfuse SSO integration take, and what drives the timeline?

The duration depends on the identity provider, how many environments need configuration, and how much of the identity model you need to design. A single OIDC application in one environment is a small task. Timelines grow when your team must define group-to-role mapping, enforce SSO by email domain, add SCIM provisioning, or test with several identity providers. Other drivers include how quickly your identity team can create and review the OIDC application, whether a staging instance exists, and how many approval rounds your change process requires. Ask any provider for a fixed-scope timeline that lists these dependencies.

What does the client need to provide for a Langfuse SSO project?

The work needs administrative access to your identity provider or a named administrator who can create OIDC applications, set redirect URIs and manage groups. It also needs a named internal owner who makes decisions on role mapping and domain enforcement, a set of test users covering each role and each email domain, access to the Langfuse deployment and its secrets store, and change windows for the production cutover. Confirm these inputs early. Missing identity admin access is one of the most common reasons an integration stalls.

Can our internal team set up Langfuse SSO without outside help?

Often, yes, if your team already operates the identity provider and the Langfuse deployment. The core configuration is an OIDC client, a few environment variables and a redirect URI, so an experienced platform or identity engineer can complete a basic setup with the Langfuse documentation. The effort rises when you add domain enforcement, role mapping, SCIM, multiple environments or audit evidence for an assessment. Estimate your own capacity honestly, and ask whether anyone has tested a rollback and a lockout recovery path before you rely on SSO-only access.

What does a fixed-scope Langfuse SSO engagement cover?

A fixed-scope engagement from DeployOpen is agreed in writing before work starts. It typically defines the identity providers in scope, the Langfuse environments, the sign-in methods to keep or disable, domain enforcement rules, any role mapping, the testing plan with test users, documentation of the configuration, and handover to your team. Items outside the written scope, such as SCIM provisioning or Enterprise features, need their own agreed scope. Get a written quote based on that scope, and ask the provider to list what is excluded so you can compare proposals on equal terms.

What should a written quote for Langfuse SSO work include?

A useful quote lists each deliverable, the identity provider and Langfuse versions it covers, the environments, the features that need an Enterprise key and who will acquire that key, the client inputs listed above, the testing and cutover approach, and the exclusions. Ask whether any cost recurs, such as support or a separate license, and whether a change to the scope after signing is priced separately. Confirm current feature availability with Langfuse for your version before you sign, since the quote is only as reliable as the feature list it is based on.

How DeployOpen scopes, builds and hands over Langfuse SSO

DeployOpen connects your self-hosted Langfuse instance to your existing identity provider inside your own infrastructure, then documents and hands over the configuration. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Confirm which identity provider you use, such as Okta, Entra ID, Keycloak or another OIDC provider, and who administers it.
Agree which email domains must sign in through SSO and whether password sign-up will be disabled.
Identify which roles need project-level access, and whether SCIM or other Enterprise-only features are required.

How we build

Register Langfuse as an application in your identity provider and configure the callback and redirect URLs for your environment.
Set the SSO provider and domain enforcement settings in the Langfuse deployment, then test sign-in with representative accounts.
Verify that disabled password sign-in and blocked sign-up behave as agreed, and that secrets are stored in your secret management system.

How we hand over

Deliver a written runbook covering provider settings, domain rules, secret rotation and how to add or remove users.
Document which features depend on an Enterprise license key and confirm with you which of them your team needs.
Walk your administrators through the configuration and record the verification results for your audit trail.

How we support

Offer ongoing support, upgrades and testing as a retainer if you want DeployOpen to keep the integration current.
Review identity provider or Langfuse version changes that could affect sign-in before you apply them.
Confirm with your vendor which support tier covers SSO issues, since Langfuse's Enterprise plan is priced separately.

Langfuse SSO and identity integration