Repository navigation
feat(sso): several SSO connections per organization - #7077
Merged
Merged
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub. 4 Skipped Deployments
|
Contributor
Warden: advisory — confidentiality findingsConfidentiality review flagged 1 item that may identify a customer, prospect, partner, or outside person (see Warden does not block merging or grant or withdraw approvals. Tests and human review remain separate requirements. Reviewed |
Behind multipleSsoConnections (cloud and self-hosted, off). An organization can add several SSO connections, each with its own identity provider, name and one or more email domains, verified, tested and enabled on its own. Sign-in lists every ready provider that covers the email, and a sign-in through any of them satisfies Require SSO.
A full install over the server snapshot's filtered install can hoist the landing site's @types/react 18 where Next's own declarations find it, so Den Web's type check fails on ReactNode (dev too). Point the hidden hoist at Den Web's version. Freshly built snapshots run MySQL 8, whose root@localhost uses auth_socket and ignores the password Den connects with; give it a password plugin.
OmarMcAdam
force-pushed
the
multiple-sso-providers-per-org
branch
from
November 6, 2026 00:06
5b8262a to
1eec1a3
Compare
MySQL has no CREATE INDEX / ADD COLUMN IF NOT EXISTS, so each step checks information_schema first and runs through a prepared statement, as 0004_organization_plugin does.
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this about?
Den SSO: an organization can set up several SSO connections, each with its own identity provider and one or more email domains, and people pick their provider at sign-in.
What problem does it solve?
Organizations with more than one identity provider (an acquisition, contractors on a separate tenant) or several email domains could not bring them all into OpenWork; one connection with one domain was the limit.
What was the situation before?
The SSO page edited a single connection with a single domain. Adding another provider meant replacing the first one, and sign-in always went to that one provider.
How is this implemented?
multipleSsoConnections(cloud and self-hosted, off); internal doc:docs/features/multiple-sso-connections/README.md. Safe to kill: every enabled connection keeps signing people in, and the SSO page goes back to managing the oldest connection.sso_connection.organization_idno longer unique, newnamecolumn (migration0183_multiple_sso_connections). Domains are stored comma separated, Better Auth's multi-domain format, and matched withFIND_IN_SET(sso-domains.ts)./v1/sso/connections(list, add, get, rename, delete, test, enable, disable, domain verification, metadata per connection)./v1/sso/*keeps managing the oldest connection. A connection added next to others uses its own id as provider id (the org-derived id plus a suffix exceeds Better Auth's 63-character DNS label).login-optionsreturnsssoProviders; new publicGET /v1/auth/sso-optionsfeeds/sso/<slug>. A/sign-in/ssonaming only an org, domain or email now gets the ready connection Den picked instead of Better Auth's arbitrary one.sso-connection-panel.tsxmanages one; sign-in shows one button per provider.What else changed?
sso_connection.renamedaudit event; connection audit snapshots includename.sso-connection-panel.tsx(no behavior change with the flag off)..devcontainer/start-daytona-server.sh: Den on Daytona could not build Den Web (dev too): a full install over the snapshot's filtered install hoists the landing site's@types/react18 where Next's declarations find it. The script now points that hoist at Den Web's version. Freshly built server snapshots run MySQL 8 (root usesauth_socket), so the script gives root a password plugin.Release note
Organizations can connect several identity providers and email domains for single sign-on, and people choose their provider when they sign in.
Evidence
evals/proofs/sso-multiple-connections.proof.test.ts(passes locally and on Daytona against this branch): an owner sees three connections with their states, opens and adds one; someone on the domain gets "Continue with Okta" and "Continue with Microsoft Entra ID"; the subsidiary domain gets only its provider;/sso/<slug>offers the same choice. Real OIDC sign-ins, per-connection tests and enable/disable are covered inee/apps/den-api/test/api/sso-multiple-connections.api.test.ts.Design: P1, P6, S2, C1, V2