Setting up single sign-on

Single sign-on lets people reach Pytheus with the account they already have, and lets you switch it off in one place when someone leaves. The setup runs as a guided sequence with a review step before anything goes live.

Before you start

You need administrative access to your identity provider and somewhere to note the values you will exchange. Have a second admin available who can still sign in with a password while you work, which is the simplest protection against locking yourself out.

Choosing a protocol

Both OpenID Connect and SAML are supported, and neither is second class. Use whichever your identity provider does better. If you have no preference, OpenID Connect is usually the shorter setup.

Microsoft Entra has a preset that pre-fills what it can and adds an extra tenant check. Everything else connects through the generic path: Okta, Google Workspace, Auth0, Ping, JumpCloud, ADFS and Keycloak all work without being on a list.

Providing the details

For OpenID Connect, supply the issuer and Pytheus runs discovery against it to find the rest.

For SAML you have three options: paste the metadata XML, give a metadata URL, or enter the sign-on URL and certificate by hand. Pasting metadata fills in the issuer, sign-on URL, certificate and name identifier format in one step and is the least error-prone.

Review, then test

A review step sits between entering details and switching anything on, so a mistyped issuer is caught before it becomes a broken connection. Test the connection before you raise the sign-in policy. A connection that saves cleanly is not the same as a connection that works.

Next: The sign-in policy.