Single sign-on (SSO)
Connect SAML 2.0 or OIDC with domain-based discovery — your team signs in with the identity provider they already use.
How it works
- Protocols. Both SAML 2.0 and OIDC are supported. Pick whichever your identity provider handles best; capabilities are equivalent.
- Domain-based discovery. Once your email domain is verified, users who enter a matching address on the sign-in page are routed to your identity provider automatically — no tenant-specific URL to distribute.
- Attribute and group mapping. Assertions and claims map to profile attributes, and IdP groups can map to roles in The Quantum Club, so access follows your directory.
- Security. OIDC discovery and metadata URLs must be public HTTPS endpoints; internal or private-network addresses are rejected at configuration time.
SSO governs authentication. For automated user lifecycle (create, update, suspend, deprovision), pair it with SCIM provisioning.
Configure SSO
Create the application in your IdP
Create a SAML 2.0 or OIDC application. The Quantum Club provides the service-provider details (ACS URL and entity ID for SAML; redirect URI for OIDC) in the admin security settings at os.thequantumclub.com.
Register the connection
In the admin security settings, add your IdP metadata: the metadata URL or XML for SAML, or the issuer and discovery URL plus client credentials for OIDC.
Verify your domain
Add your email domain so discovery can route your users. Until verification completes, SSO can be tested by direct initiation but is not auto-discovered.
Map attributes and groups
Confirm email, given name, and family name mappings. Optionally map IdP groups to roles so role assignment is directory-driven.
Test with one user
Sign in with a test account from your IdP before announcing the rollout. Check the resulting profile attributes and role.
Identity provider notes
Create the app integration in the Okta admin console and choose SAML 2.0 or OIDC. Okta's default profile attributes map cleanly to the expected email and name fields. If you also plan SCIM provisioning, note that Okta configures it on the same app under Provisioning — see SCIM.
Use Enterprise applications → New application. Entra ID works with either protocol; for SAML, confirm the Name ID format is the user's email. Group claims must be enabled explicitly in the token configuration if you intend group-to-role mapping. Provisioning is configured separately — see SCIM.
Configure a custom SAML app from the Google Admin console. Map primary email to the email attribute and first/last name accordingly. Google Workspace has no native SCIM client for custom apps; if you need automated provisioning, route it through a SCIM-capable proxy.
Troubleshooting
A test user signs in via your IdP, lands with correct name and email, and receives the expected role.
Vulnerability disclosure
How to report a security vulnerability in The Quantum Club, what is in scope, and what to expect when you do — our coordinated disclosure policy and safe-harbor commitment.
SCIM provisioning
Connect your identity provider over SCIM 2.0 so joiners, changes, and leavers propagate without a human in the loop.