Skip to content

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, scopes openid email profile, and the authorization code flow with PKCE (S256).

Create the connection ​

http
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"
}
FieldRule
domains1–20 verified domains of this org, not already routed by another connection (409 otherwise).
client_secret_refA secret reference (env:, kms: or sm:), never the secret itself. Responses show has_client_secret.
default_roleOptional 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 ​

  1. On the sign-in page the person enters their email. POST /auth/sso/discover looks up an active connection for the email's domain and returns its start URL.
  2. Axiom redirects to your identity provider with state, nonce and a PKCE challenge.
  3. 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: false is refused).
  4. 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:

  • auditor lets every SSO user read and export evidence across the org.
  • approver makes every SSO user an eligible, notified approver for approvals whose required role is approver in any org tenant, including at resume; see Approvers and approval modes.
  • app_owner lets 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.

Developer preview. Contract version 2026-11-14.