Single sign-on overview

Connect your existing directory so that access to Seylo is granted where you already grant everything else, and revoked the same way.

Supported providers

Microsoft Entra IDOIDC. App roles or groups.

Google WorkspaceOIDC. Read the two consequences first.

OktaOIDC. The groups claim needs adding.

Auth0, Keycloak, generic OIDCAny conformant OIDC provider.

SAML 2.0AWS IAM Identity Center, AD FS, generic SAML.

Before you start

You need	Why
admin in Seylo	SSO configuration is administrator-only
Administrative access to your directory	You will create an app registration and, usually, add a claim
To know how your roles are expressed	Groups? App roles? A custom claim? This is the part that goes wrong

Configuration lives under Single sign-on in the portal.

The one concept to understand first: the tenant key

Seylo identifies your organisation from the token’s issuer, plus — where the issuer is not unique to you — a discriminator claim.

That second part exists for one reason: Entra ID gives every directory its own issuer, but Google Workspace gives every organisation on earth the same issuer, https://accounts.google.com. The issuer alone cannot tell your Workspace from anyone else’s.

Provider	Discriminator	Required?
Entra ID, single directory	—	No. The issuer already embeds your directory ID
Entra ID, multi-tenant app	tid	Recommended
Google Workspace	hd	Yes
Okta	—	No. One issuer per org or authorization server
Auth0 without Organizations	—	No
Auth0 with Organizations	org_id	Recommended
Keycloak	—	No. One issuer per realm

Three behaviours follow, and all three are deliberate:

• No discriminator configured → the issuer alone resolves your organisation.
• Configured but absent from the token → rejected. Never “try the other organisations”, never “use the default”. A Google token with no hd is a personal Gmail account and must not land in a Workspace organisation.
• Present but unmatched → rejected, naming the claim and the value that arrived. It never falls through to another organisation sharing the issuer, and the message names no other organisation.

Why this matters more than it looks

On a shared issuer the signature is valid for every customer of that provider. The discriminator is therefore not a convenience — it is the isolation boundary. Seylo reads it twice: once from the unverified payload to select a configuration, and again from the verified claims, which must agree.

What Seylo enforces on every sign-in

You do not configure any of this; it is worth knowing it is there.

• Signature verified against that issuer’s published keys, fetched over https from a discovery document that must declare the issuer it was served from.
• Only asymmetric algorithms. HS256 and none are refused — with HS* the signing key is the client secret, which is not a signature in any useful sense.
• Audience checked against your registered audiences; expiry and not-before enforced.
• An unknown issuer is a 401, never a fallback to some default organisation.
• An (issuer, discriminator) pair already owned by another organisation cannot be taken over. Moving one is an explicit delete then add, because a registration is a trust anchor.

For SAML, signature validation uses @node-saml/node-saml rather than hand-rolled XML handling: it verifies the bytes the signature actually covered (which is what defeats signature-wrapping attacks) and validates only against the certificate you configured — never one embedded in the received document.

Recommended order

1. Register Seylo in your directory and configure the provider here.
2. Run test login before telling anyone it works. It shows the complete claim set and says, per value, whether each role mapped and why not.
3. Set up role mapping.
4. Close self-service signup — see managing users.
5. Read break-glass recovery before you need it.

The most common failure is not a failure

“SSO works but nobody has any permissions” is the single most reported problem, and it is almost never an authentication bug. It is a role claim that did not resolve — most often Keycloak’s nested path, Okta’s absent groups claim, or an Auth0 claim that was never namespaced. Test login tells you which in one screen.