¶Single sign-on

OpenID Connect: Okta, Entra ID, Google Workspace, Auth0, Keycloak, JumpCloud, OneLogin.

Platform → Single sign-on. Platform admins only.

¶Why it is a platform setting, not a workspace one

This is not a policy decision; it is forced by the data model.

An account in Félagi belongs to a person, and a person can be in several workspaces. Authentication happens before anybody has chosen a workspace — there is no workspace to consult when somebody arrives at the login page. So a workspace-level identity provider could not be found in time to be used.

¶Four fields

Issuer          https://acme.okta.com
Client ID       0oa1b2c3…
Client secret   …
Email domains   acme.com, acme.co.uk

Everything else is discovered from the issuer's /.well-known/openid-configuration, so a provider that moves a URL keeps working. Discovery is attempted before the provider is saved: a provider that cannot be reached is a login page that fails for everybody on that domain, and finding that out now beats hearing it from them.

Give your provider this redirect URI, which the page shows:

https://felagi.example.com/auth/sso/callback

¶Identifier-first

Somebody types their work email and is sent to the right provider. A login page with four sign in with buttons asks every user a question only their administrator can answer.

Domains are matched exactly. acme.com does not own evil-acme.com or eu.acme.com — a suffix match would hand somebody else's accounts to whoever registered a lookalike.

¶What happens on the way back

The audience check is the one people leave out. Without it, anybody holding a token from the same provider — for any other application registered with it — could sign in here as its owner.

¶The ID token's signature is deliberately not verified

That is the specification's position, not a shortcut. OpenID Connect Core §3.1.3.7:

If the ID Token is received via direct communication between the Client and the Token Endpoint (which it is in this flow), the TLS server validation MAY be used to validate the issuer in place of checking the token signature.

Which is exactly this situation. The token is fetched server-to-server over TLS, from an endpoint named in a discovery document whose issuer we checked, and the request is authenticated with a client secret only we hold. Félagi refuses a token endpoint that is not https, because the whole argument rests on it.

The alternative was hand-rolling RS256 verification. A verifier that accepts alg: none, or HS256 against the public key, is the single most common way this is got wrong — and it would be a worse trade than the one the spec already sanctions.

¶Accounts

Matched on sub, the provider's subject claim — not on email. sub is the one thing a provider promises is stable. Matching on email would mean a rename creates a second account, and recycling an address inherits one.

An existing account with that address is claimed, not duplicated, and keeps its role. Single sign-on decides who somebody is, not what they may do.

A new account is created only if a workspace is configured for that provider, and only for a domain the provider owns. Otherwise somebody signs in to nothing, which is worse than being told to ask for an invitation.

Nothing is created for an address the provider has not verified. A provider that hands out unverified addresses is one where somebody can type a colleague's address into their own profile — and that address decides whose workspace they land in.

¶Refusing passwords

Tick Refuse passwords for these domains and a password is rejected for those addresses even when it is correct.

This is the reason an enterprise buys single sign-on. An account that can still be reached with a password has not been centralised; it has been duplicated.

Everybody else keeps using a password.

¶Two-factor

By default, signing in through a provider counts as the second factor. The provider did MFA, and asking for a Félagi code as well is theatre.

It is a per-provider setting rather than an assumption, because a provider configured without MFA would otherwise silently satisfy a requirement it does not meet.

Turning it off means those people are asked for a Félagi code too.

¶Removing a provider

The accounts stay. Their people go back to a password — deleting somebody's account because an integration was removed is not a reasonable outcome, and they can use the forgotten-password flow.

¶Not there yet

• No SAML. OIDC covers Okta, Entra ID, Google Workspace, Auth0, Keycloak and most of the rest. SAML means XML signature verification, where signature wrapping attacks are a genuine and well-documented hazard — that needs a maintained library rather than a weekend, and it is honest to say so instead of shipping something that looks like SAML.
• No SCIM. Accounts are created on first sign-in, not provisioned in advance, and deprovisioning is not automatic: removing somebody at the provider stops them signing in, but their membership here stays until it is removed. For a clean offboarding, remove them from the workspace too.
• No group or role mapping. Everybody arrives as the configured default role.
• One provider per domain. Two providers claiming acme.com is not resolved; the first enabled one wins.
• No provider-initiated sign-in. Start from Félagi's login page.