Single sign-on
People sign in to Axiom with passkeys, an email magic link, or their organisation's OIDC identity provider. SSO chooses how someone signs in; it never by itself gives access to a project. Project and tenant access always come from memberships and invitations.
Console: SSO connections at /control/orgs/:oid/sso. You need org_admin.
Prerequisites
- A verified organisation with the domains you want to route (see Enrolling existing projects). SSO domains must be verified domains of your org.
- An OIDC client registered in your identity provider with redirect URI
https://api.sectigoaxiom.com/auth/sso/callback, scopesopenid email profile, and the authorization code flow with PKCE (S256).
Create the connection
POST /v1/orgs/{oid}/sso-connections
content-type: application/json
{
"protocol": "oidc",
"issuer": "https://login.acme.example",
"discovery_url": "https://login.acme.example/.well-known/openid-configuration",
"client_id": "axiom-console",
"client_secret_ref": "env:ACME_OIDC_CLIENT_SECRET",
"domains": ["acme.example"],
"default_role": "auditor"
}| Field | Rule |
|---|---|
domains | 1–20 verified domains of this org, not already routed by another connection (409 otherwise). |
client_secret_ref | A secret reference (env:, kms: or sm:), never the secret itself. Responses show has_client_secret. |
default_role | Optional org role granted on SSO sign-in: app_owner, approver or auditor only. |
PATCH /v1/sso-connections/{id} changes fields or sets status: "active" | "disabled"; DELETE returns the connection with status: "deleted".
How sign-in works
- On the sign-in page the person enters their email.
POST /auth/sso/discoverlooks up an active connection for the email's domain and returns its start URL. - Axiom redirects to your identity provider with
state,nonceand a PKCE challenge. - On return, Axiom exchanges the code, validates the ID token (issuer, audience, nonce) and requires an email address that is not explicitly unverified (
email_verified: falseis refused). - The person is signed in. If the connection has a
default_role, they are added to the org with that role. Nothing is granted on any project or tenant.
Sessions are opaque random tokens (only their SHA-256 is stored) in HttpOnly; Secure; SameSite=Lax cookies scoped to .sectigoaxiom.com.
Choosing a default role
An org role applies to every tenant the org owns and every project enrolled in it. Choose with care:
auditorlets every SSO user read and export evidence across the org.approvermakes every SSO user an eligible, notified approver for approvals whose required role isapproverin any org tenant, including at resume; see Approvers and approval modes.app_ownerlets every SSO user read and configure (project.write) the org's enrolled projects.
Leave default_role empty if you prefer to assign roles explicitly with POST /v1/orgs/{oid}/members ({ email, role }) or on the tenant's Members and approvers screen.
Other sign-in methods
Passkeys and magic links keep working for everyone, including people in SSO domains. Disable an account in your identity provider and remove its Axiom memberships to cut access; existing sessions end when they expire or the person signs out.