Single Sign-On (SSO)
Require everyone in your organization to authenticate with your own identity provider before they can reach the organization dashboard.
SSO sits on top of Discord sign-in, it does not replace it
Members still sign in with Discord first. SSO is a second check applied to your organization's area. This is deliberate: Ticket Tool manages Discord servers, and a person's permissions inside those servers are Discord permissions, so their Discord identity is what the product is built around.
What you need
Any identity provider that speaks OpenID Connect, including Okta, Auth0, Microsoft Entra ID, Google Workspace, Keycloak and Authentik.
Inside that provider you create one application:
| Setting | Value |
|---|---|
| Application type | Web (a confidential client) |
| Grant type | Authorization Code |
| Scopes | openid email profile |
| Sign-in redirect URI | Shown on your organization's Security settings page |
It must be a confidential client
A single-page or native application has no client secret, and the sign-in cannot be completed without one. If your provider asks you to choose, pick the option described as a web, server-side or confidential application.
Setting it up
Create the application in your provider
Use the settings in the table above. Copy the sign-in redirect URI from Organization settings → Security and paste it into your provider exactly as shown, including the scheme and any trailing characters. Providers reject a sign-in whose redirect URI differs by even one character.
Fill in the configuration
Back in Organization settings → Security, enter:
- Issuer URL: the address your provider publishes its OpenID configuration under. Okta is usually
https://your-org.okta.com/oauth2/default, Auth0https://your-tenant.auth0.com/, Entrahttps://login.microsoftonline.com/<tenant>/v2.0. A trailing slash is fine. - Client ID and Client secret from the application you just created.
- Allowed email domains (optional), covered below.
Run a test sign-in
Click Test sign-in. You are sent to your provider and returned to the organization. This has to succeed at least once before enforcement can be switched on, so that you cannot lock your team out behind a provider nobody has authenticated with.
Turn on enforcement
Switch Require for all members on. From that point, every member is sent to your identity provider before they can reach the organization.
Restricting by email domain
Leave Allowed email domains empty to accept any account your provider vouches for.
Enter one or more domains to accept only those. The check uses the email address your provider asserts, and only when your provider has marked it verified. An unverified address cannot satisfy a domain restriction.
Narrowing the list switches enforcement back off and asks for a fresh test sign-in, so a typo cannot lock out your organization.
If your provider stops working
Certificates expire, secrets get rotated, and tenants get disabled. Two things make that recoverable:
- Organization settings stays reachable even while the gate is unsatisfied. It is where you turn enforcement off.
- Changing enforcement requires two-factor authentication on your own account. That is why enforcement cannot be enabled until you have 2FA set up: it is the credential that proves who you are when your identity provider cannot.
Set up two-factor authentication first
The Require for all members toggle stays disabled until the organization owner has 2FA enrolled, because 2FA is the recovery path.
What SSO does and does not cover
It applies to the organization dashboard and to organization data reached through the API, including tickets and transcripts across every member server.
It does not change how people sign in to an individual server's dashboard, and it does not apply to Discord itself. Someone removed from your identity provider keeps whatever access their Discord account gives them inside your Discord servers; removing them there is still a separate step.
Ticket Tool staff acting under an audited support elevation are not gated, so that we can still help you if your provider is the thing that has broken.
Sign-in problems
| What you see | What it means |
|---|---|
| That email domain is not permitted | The account your provider returned is outside the allowed domains, or its email is not verified |
| We could not complete the sign-in | The client secret is wrong, or the provider rejected the exchange |
| Your identity provider refused the request | The provider declined, often an unassigned user or a consent prompt that was cancelled |
| Issuer mismatch | The issuer you entered does not match the one the provider publishes |
Every configuration change and every successful sign-in is recorded in your organization's audit log.