Set up single sign-on

With SSO, your team signs in through your own identity provider. Access follows the accounts your IT team already manages, so somebody leaving the company loses Gleap along with everything else.

Gleap's SSO is OpenID Connect. If your provider offers OIDC — nearly all do — you're set. There is no SAML.

What you need from your provider

Create an OIDC application there, and keep four things to hand:

• Issuer URL — e.g. https://accounts.google.com.

• Client ID.

• Client Secret.

• Scope — openid email profile covers it.

Gleap's settings screen shows the redirect URI to register in your provider. Copy it exactly — a mismatch there is the single most common reason a first attempt fails, and providers reject it rather than explaining.

Configure it in Gleap

Pick a provider template — Google Workspace, Azure AD, Okta, or Custom — which fills in what it can, then enter your issuer, client ID, secret, and scope.

Then two settings that matter more than they look:

Allowed domains

Restricts SSO to particular email domains. Leave it empty, and any domain your provider authenticates is accepted. Set it to your own domains unless you have a reason not to.

Default role

The role everyone signing in via SSO receives. This is the decision to think about: it applies to every new person automatically, so setting it to Administrator makes everyone who can authenticate an administrator.

Set the default to the lowest role that lets people do their job, and promote individuals afterwards. It's much easier than discovering later that thirty people can change your billing.

Finally, switch Enable SSO on and save.

Signing in with it

The settings screen shows an SSO login URL. That's the link to give your team, or to put behind whatever “apps” launcher your provider offers — people arrive already authenticated, without going through the normal login screen.

Test it with a second account

Before you tell the team, sign in through the SSO URL as somebody who isn't you — ideally in a private window. That's what confirms the redirect URI, the allowed domains, and the default role are all actually right; testing with your own already-signed-in session proves nothing.

When it doesn't work

Most failures are one of three things: the redirect URI doesn't match, the scope is missing email so Gleap can't identify the person, or their address is on a domain you didn't allow.

The error your provider shows is usually more specific than the one Gleap can display, so read that first.