Single sign-on (SSO)

Single sign-on lets your colleagues sign in to Rixe with the account they already use at work, through your identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace or any other provider that speaks SAML 2.0 or OpenID Connect. The IdP holds the password and decides who gets in; Rixe creates accounts and sets roles from what the IdP tells it. You need this when your security policy requires central control over who can reach company tools.

#Availability

Single sign-on is included in the Leader, Agency Network and Agency Custom plans; on Enterprise contracts it is part of the agreed limits. On other plans the API refuses to save a connection with "Single sign-on needs the Leader plan or an agency contract." See Plans and limits.

Each organisation has one SSO connection, tied to one email domain.

#What you need to set it up

There is no SSO setup form in the panel yet: the connection is created with the Rixe team, on behalf of the organisation's owner. Prepare the values for your protocol.

#SAML 2.0

Create an application in your IdP with these settings:

Then send us:

• the IdP's single sign-on URL (the entry point),
• the issuer (entity ID) for the Rixe application,
• the IdP's signing certificate.

#OpenID Connect

Register a web application in your IdP with the redirect URI https://app.rixe.ai/api/sso/oidc/callback. Rixe requests the openid email profile scopes and uses PKCE and a nonce on every sign-in. Send us:

• the discovery URL (the issuer's /.well-known/openid-configuration),
• the client ID,
• the client secret.

The client secret is stored encrypted and is never shown again, not even to the owner who entered it. If you want group-based roles, add a groups claim to the ID token.

#Options for both protocols

#How sign-in works

1. On the sign-in screen, click Sign in with SSO.
2. Enter your Work email and click Continue.
3. Rixe looks up the email domain and sends you to your IdP. After you sign in there, you come back to Rixe signed in.

If the domain has no SSO connection, the screen says "SSO is not set up for this email domain" and you can sign in with your email and password instead. If the IdP's answer cannot be verified, the screen says "SSO sign-in could not be completed" and nothing is signed in.

Every answer from the IdP is checked before anyone is let in: the SAML signature, audience, validity window and request ID, or the OIDC token's signature, issuer, audience, expiry and nonce. The values that tie a sign-in to your browser travel in a short-lived signed cookie, never in a URL.

#Accounts are created on first sign-in

You don't need to invite SSO users. The first time someone your IdP vouches for signs in, Rixe creates their account (with no password — the IdP holds the credential) and adds them to your organisation. Someone who already had a Rixe account keeps it and is added as a member.

#Roles come from your groups, on every sign-in

Rixe reads the groups the IdP sends and gives the person the role mapped to them. If someone is in several mapped groups, the most privileged role wins: a person in both an "admins" and a "viewers" group becomes Admin. Anyone in no mapped group gets the default role.

The mapping is applied again at every sign-in, so the IdP stays the source of truth. A role changed by hand under Settings › People is replaced the next time that person signs in through SSO. See Team and roles.

#Enforcing SSO

When SSO is enforced, nobody with an address on that domain can sign in with a password or with Google or Microsoft — the sign-in is refused with "Single sign-on (SSO) is required for this account" and they have to use Sign in with SSO.

Two safety rules apply:

• The owner can only enforce SSO for the domain of their own sign-in email.
• SSO cannot be enforced for public email providers such as gmail.com or outlook.com.

#SCIM provisioning

With SCIM, your IdP tells Rixe when people join or leave, without anyone signing in. SCIM needs an SSO connection first.

1. The owner generates a SCIM token. It is shown once; only a hash of it is stored, so copy it into your IdP straight away.
2. In your IdP, set the SCIM base URL to https://app.rixe.ai/api/scim/v2 and use the token as the bearer token.

Rixe supports the SCIM 2.0 Users resource:

Deactivation takes effect quickly: existing sessions stop working within about a minute, not when the session would otherwise expire. A deactivated user's record is kept (without access) so the audit log can still name who did what.

#Common questions

Can I have more than one domain? One connection per organisation, for one email domain.

What happens to existing password users when I enforce SSO? They keep their account and data, but from then on must sign in through Sign in with SSO.

Someone was removed at the IdP but is still in the member list. Without SCIM, Rixe only learns about people when they sign in. Remove them under Settings › People, or set up SCIM so deactivation reaches Rixe automatically.

#Related pages

• Team and roles
• Governance
• Data and security