Skip to main content

Single Sign-On (SSO)

The easiest way to create an account or log into Trace.Space is to use your existing Google or Github account with OAuth 2.0. Alternatively setup SSO with any Identity Provider supporting OIDC.

Written by Janis Vavere

OAuth 2.0 with Google or Github

The easiest way to create an account or log into Trace.Space is to use your existing Google or Github account with OAuth 2.0 - no setup steps required. A Microsoft button appears only on deployments where it has been configured.

Setup SSO with any Identity Provider supporting OIDC

Trace.Space supports single sign-on with any OIDC-compatible identity provider (Okta, Azure AD / Entra ID, Auth0, or a custom OIDC provider). Once enabled, members whose email domain matches your configuration can sign in through your provider.

Before you start (prerequisites)

You'll need:

  • Organization admin permissions - only org admins can view or change SSO settings.

  • An OIDC application registered in your identity provider, configured as a Web / confidential app using the Authorization Code flow (PKCE), with the openid, email, and profile scopes released. From it, collect:

    • Issuer URL - your provider's OIDC discovery endpoint (e.g. https://your-domain.okta.com). Must be HTTPS and publicly reachable.

    • Client ID

    • Client secret

  • Email domain(s) you own (e.g. acme.com) - these decide who can use SSO. A domain can only be claimed by one organization.

  • The Callback URL, which Trace.Space generates for you on the SSO page (you'll paste it into your provider).

Step 1 - Open the SSO settings

Click the settings gear in the top bar, choose Organization settings, then select SSO in the left sidebar (under your organization).

The SSO configuration page under Organization settings, with the provider fields, the Callback URL and the Enable SSO toggle

Step 2 - Register the callback URL in your provider

On the SSO page, find the Callback URL field and click the copy icon. In your identity provider's OIDC app, add this exact value to the Allowed callback URLs (sometimes called Redirect URIs), then save.

Step 3 - Fill in the SSO configuration

Back on the Trace.Space SSO page, complete the fields:

Field

What to enter

Provider

Pick your provider: Okta, Azure AD, Auth0, or Custom OIDC.

Issuer URL

Your OIDC discovery endpoint, e.g. https://your-domain.okta.com (HTTPS required).

Client ID

The Client ID from your provider's app.

Client secret

The Client secret from your provider's app.

Email domains

Type each domain and press Enter (e.g. acme.com). You can add several.

Step 4 - Save

Click Save. Your settings are stored, and the client secret is encrypted at rest (it's never displayed again - when editing later, leave it blank to keep the existing secret).

Step 5 - Enable SSO

The Enable SSO toggle stays disabled until all five fields (provider, issuer URL, client ID, client secret, and at least one email domain) have been saved. Once everything is in place, flip the toggle on - it takes effect immediately.

Step 6 - Test the login

Sign out (or use a separate browser/incognito) and go to the sign-in page. Enter an email on one of your configured domains, or the domain itself, in the SSO email or domain field and click Log in with SSO - you should be redirected to your identity provider and back into Trace.Space.


Tips & troubleshooting

For sign-in problems that are not specific to SSO, see Troubleshooting sign-in and access.

  • Toggle is grayed out - you haven't saved all required fields yet. Fill every field and click Save first; the toggle enables only after the values are persisted.

  • "Email domain already claimed" - that domain is configured for SSO in another organization; domains are unique across orgs.

  • Issuer URL rejected - it must be HTTPS and resolve to a public address (private/internal IPs are blocked for security).

  • Login works but no name/email comes through - make sure your provider's app releases the openid, email, and profile claims.

  • Provider redirect error - re-check that the callback URL in your provider exactly matches the one shown on the SSO page.

Did this answer your question?