SSO Configuration
Thallus supports enterprise single sign-on via OIDC and SAML. Org admins configure SSO for their organization; superadmins can configure it for any org. Each organization supports one SSO configuration.
Supported providers
OIDC configuration
| Field | Required | Description |
|---|---|---|
| client_id | Yes | Application ID from your identity provider |
| client_secret | Yes | Encrypted at rest in the database |
| issuer_url | Yes | Provider's issuer URL — used for OIDC auto-discovery |
| scopes | No | Defaults to openid, profile, email |
The issuer URL is used for auto-discovery: Thallus fetches the /.well-known/openid-configuration document to automatically determine authorization, token, and userinfo endpoints.
SAML configuration
| Field | Required | Description |
|---|---|---|
| idp_entity_id | Yes | Identity provider's entity ID |
| idp_sso_url | Yes | SSO endpoint URL at the IdP |
| idp_certificate | Yes | X.509 certificate (PEM format) for signature validation |
| sp_entity_id | No | Thallus's entity ID (auto-generated if not set) |
| attribute_mapping | No | Map IdP attributes to user fields (email, name, etc.) |
Thallus provides a SP metadata endpoint that you can import into your IdP to auto-configure the SAML trust relationship.
Behavior settings
| Setting | Default | Description |
|---|---|---|
| allow_jit_provisioning | true |
Auto-create user accounts on first SSO login |
| default_role | user |
Role assigned to JIT-provisioned users |
| require_sso | false |
When true, password login is disabled for the org |
| allowed_domains | null |
Restrict SSO to specific email domains |
When require_sso is enabled:
- Password login returns an error directing users to SSO
- Password reset is blocked for users in this org
- New users are created without a password hash
Microsoft 365 integration
For organizations using Microsoft Entra ID (Azure AD), Thallus can also integrate with Microsoft 365 services via the Graph API.
| Field | Description |
|---|---|
| m365_tenant_id | Azure AD tenant ID |
| m365_scopes | Graph API permissions for the capabilities you want to enable |
The Microsoft 365 integration requests the necessary permissions for email, calendar, files, and contacts based on your configuration. Tokens are securely stored per-user and refreshed automatically when they expire.
SSO login flow
- Initiate — User selects SSO login. Thallus looks up the SSO config for the user's org (by email domain)
- Redirect — Thallus generates an authorization URL with state parameter and redirects to the IdP
- Authenticate — User authenticates at the IdP (password, MFA, etc.)
- Callback — IdP redirects back with an authorization code (OIDC) or SAML assertion. Thallus validates the response
- Provision/Link — If JIT provisioning is enabled and the user doesn't exist, a new account is created. Otherwise, the SSO identity is linked to the existing account
- Session — JWT access token and refresh token are issued. The SSO identity's
last_login_atis updated
Testing configuration
Before enabling SSO for your organization, use the test endpoint to validate your configuration:
- OIDC: Tests that the issuer URL's discovery document is reachable and contains valid endpoints
- SAML: Validates the IdP certificate format and attribute mapping
Testing does not create user sessions — it only verifies the configuration is well-formed.
Managing SSO identities
Admins can view and manage SSO identities linked to users:
- View — See which IdP identity is linked, last login date, and cached claims
- Unlink — Remove the SSO identity link (user reverts to password login if available)
- M365 tokens — View token expiry status for Microsoft 365 integrations
A user can have multiple SSO identities if their org changes providers. Old identities remain until explicitly unlinked.
Related pages
- Security Settings — User-facing password and session settings
- User Management — Create users (password vs SSO-only)
- Connecting Integrations — OAuth for agent integrations (separate from SSO)
- Audit Logs — Track SSO login events