Problem
A team on the platform today is a list of people who each signed in with Google, GitHub, a passkey or an e-mail code, and were invited one by one. That is fine for five engineers. A company with an identity provider (Okta, Microsoft Entra ID, Google Workspace) wants three more things before its security team says yes:
- Sign-in through its own provider. Its people use the company account they already have, with the company's own password rules, second factor and device checks.
- One switch to cut access. When someone leaves, disabling them in the identity provider must end their access here too, without anyone remembering to remove them.
- Proof. Who joined, who left, and who signed in how, on record.
The team's audit log, its two-factor and domain policy, and the audit stream to the customer's own systems are already in place. What is missing is the identity provider in the loop.
What the identity stack can and cannot do
Sign-in runs on and , open source under Apache 2.0. can add any OpenID Connect provider as a sign-in method and map its claims to the identity with a Jsonnet mapper (social sign-in data mapping). Those providers are global configuration: one list for everyone, read at start.
Per-organisation single sign-on (an organisation with its own OIDC or SAML connection, chosen by e-mail domain), SAML itself and SCIM provisioning are not in the open-source . ships them in Network and in the self-hosted Enterprise License (OEL, under OEL).
Polis, formerly BoxyHQ Jackson, is open source under Apache 2.0. It bridges a SAML sign-in to OpenID Connect and serves SCIM 2.0 directory sync (ory/polis).
Proposal
Build it in three steps, each useful on its own. The first does not depend on a licence decision.
1. OpenID Connect per team, with a verified domain
- Verify a domain. A team's owner adds
company.hrand proves it with a DNS TXT record (_inorbit-verify.company.hr), checked by the accounts service. A domain is verified for one team at a time. - Add the connection. The owner registers the company's OIDC application: issuer,
client id and secret. The secret is sealed at rest like a webhook secret and never
shown again. The accounts service writes it into as one more OIDC provider,
team-<slug>, with a mapper that accepts only verified addresses in the team's domains (thehdclaim for Google Workspace, the address for others). Adding a provider means a configuration reload. That is acceptable at tens of teams; past that, step 3's licence decision comes due. - Find it at sign-in. The sign-in page asks for the e-mail first. An address in a verified domain goes straight to the company's provider (home realm discovery).
- Require it. "SSO required" sits beside "two-factor required" in the team's security policy, enforced in the same one role check. A member whose current session did not come through the team's provider is refused the team, with a link to sign in through it. The owner keeps a fallback sign-in, so a broken provider never locks the company out.
- Join on first sign-in. Someone signing in through the team's provider with an address in its domain joins as a member, if the owner allows that; otherwise an invitation is still needed.
A diagram is drawn here in the RFCs product; this page does not show diagrams yet.
2. SCIM 2.0 provisioning
- The protocol. A SCIM 2.0 endpoint per team (RFC 7643 for the schema, RFC 7644 for
the protocol), authenticated by a team token with the scope
team:provision. - What it does. Create, update and deactivate users and groups. Deactivating a user
removes them from the team at once, revokes their sessions on the team's hosts and
writes
member.removeto the audit log, attributed to the directory. - Groups. They map to roles: one group for admins, everyone else a member.
- Where it runs. Either Polis serves the SCIM endpoint and the accounts service consumes its events, or the accounts service implements the small subset Okta and Entra actually call. The choice is made when this step starts, by testing both against Okta's and Entra's SCIM validators.
A diagram is drawn here in the RFCs product; this page does not show diagrams yet.
3. SAML, and the licence question
SAML-only companies, mostly larger and older ones, get Polis in front: SAML in, OpenID Connect out to as in step 1.
At that point there are two stacks: generated provider configuration in plus Polis, and 's enterprise organisations. The decision between them is made when the first contract that needs SAML or SCIM is signed, by comparing the licence price with the work of keeping our own.
Alternatives considered
- Buy 's enterprise licence now. It is the least code and the most complete: organisations, SAML and SCIM in one product, with support. We pass on it for now because no paying customer needs it yet and the price is a quote, not a list. It stays the default answer once one does.
- A hosted SSO broker (WorkOS, Auth0). Quick to add, but it puts every customer's sign-in through a third party in another jurisdiction, which our data-residency answer would then have to explain. We keep identity on our own infrastructure.
- Only domain-restricted social sign-in. A Google Workspace company could already sign in with Google, and the team's allowed domains keep everyone else out. That covers the smallest companies with no work at all. It does not cover Okta or Entra, and nothing removes a person when they leave.
Decision
Open. To be decided by the owner of the platform.
Publication
The console's team Security page gains Domains, Single sign-on and Provisioning
sections. The developer docs gain a page on connecting Okta, Entra ID and Google
Workspace, with each provider's screens. The audit log gains sso.* and domain.*
actions, which also stream as audit.event.
Status log
- 2026-10-02: opened, after the team area (members, invitations, security policy, audit log and its webhook stream) was rebuilt to the level larger customers expect.
- 2026-10-07: Checked: no PR builds single sign-on (#131, #137, #173 and #178 only mention it). Domains, which it needs, are live (RFC 0030). Open.
- 2026-10-07: RFC 0083 takes this to organisations for PRD 0001's enterprise row and recommends how to do steps 2 and 3: SCIM in our own accounts service behind the edge, and one self-hosted SAML bridge in front of our identity provider. Open.