SSO, SAML, OIDC, and SCIM: Concepts

These four terms get used interchangeably, and they should not be. One is an outcome, two are login protocols, and one is a provisioning API that has nothing to do with login. This page explains what each is technically, how the mechanics differ, and which AxonFlow surface uses which - with the one wiring constraint that follows from how AxonFlow stores its SSO configuration.

If you want setup instructions instead of concepts, go to Portal Login (SSO), SCIM Provisioning, or the JumpCloud end-to-end guide.

The one-paragraph version

SSO (single sign-on) is the outcome: a person proves who they are to one identity provider and every connected application accepts that proof. SAML and OIDC are the two protocols that deliver that outcome for browser login - SAML by POSTing a signed XML assertion, OIDC by redeeming an authorization code for a signed JSON token. SCIM is neither: it is a REST API through which the identity provider pushes the user directory (who exists, which groups they are in) into an application ahead of time, so accounts and roles exist before anyone logs in.

SSO is an outcome, not a protocol

"Does AxonFlow support SSO?" is really asking "can my team sign in through our identity provider instead of a separate password?" The answer is yes - through either protocol below. When a page here says SSO, it means the outcome; when a decision depends on the wire mechanics, the page names SAML or OIDC explicitly.

SAML: the signed-document protocol

SAML 2.0 (2005) predates mobile apps and JSON APIs; it moves signed XML documents between three parties through the browser. The application (the service provider, SP) redirects the user to the identity provider (IdP); the IdP authenticates them and POSTs a signed XML assertion ("this is [email protected], authenticated at 09:14, valid for 5 minutes") back to the SP's Assertion Consumer Service (ACS) URL; the SP validates the signature against the IdP's certificate and creates a session.

Technical properties that matter in practice:

• Trust is certificate-based and pre-exchanged. The SP holds the IdP's signing certificate (usually via a metadata URL); the IdP holds the SP's entity ID and ACS URL. Both sides must agree on these exactly - most SAML failures are a mismatched ACS URL or entity ID, which is why AxonFlow derives both from SSO_BASE_URL and exposes them at GET /api/v1/sso/sp-metadata instead of asking you to hand-build them.
• The assertion travels through the browser, not server-to-server. The IdP never calls the SP directly.
• Browser-only by design. There is no sensible way for a CLI tool or an API client to complete a SAML flow; it exists to log a human into a web app.

OIDC: the token protocol

OpenID Connect (2014) is a thin identity layer on OAuth 2.0, built for a JSON/REST world. In the browser authorization-code flow, the application redirects to the IdP with its client_id; the IdP authenticates the user and redirects back with a short-lived code; the application's backend exchanges the code (authenticated with its client_secret) for a signed JSON id_token (a JWT), verifies the signature against the IdP's published JWKS (its public keys), and creates a session.

The property that makes OIDC strictly more useful than SAML for a platform like AxonFlow: a signed JWT can be verified by anyone, anywhere, statelessly. A backend that holds the IdP's issuer, expected audience, and JWKS URL can validate a token it has never seen before without a browser, a redirect, or a session. That enables a second, browserless use of the same standard:

This is token verification only - AxonFlow never runs a login flow here; it verifies proof that the IdP already issued. Note the last verification step: the user's role comes from the SCIM-synced directory, never from a claim inside the token, so a misconfigured IdP claim cannot mint an administrator.

SCIM: the provisioning API

SCIM 2.0 (RFC 7643/7644) has nothing to do with login. It is a REST API (/scim/v2/Users, /scim/v2/Groups) through which the identity provider pushes directory changes into an application on a schedule: Alice joined, Alice moved from developers to platform-admins, Alice left. The application holds a bearer token the IdP uses to authenticate its sync calls.

Two things SCIM gives you that no login protocol can:

• Provisioning before first login and deprovisioning after the last. Login protocols only fire when someone shows up; SCIM removes an offboarded user's access the moment HR removes them from the directory, whether or not they ever log in again.
• An audited authorization source. AxonFlow resolves every user's role from the SCIM-synced group-to-role mapping - the same directory your security team audits - rather than trusting whatever a token or assertion claims.

Side-by-side

	SAML 2.0	OIDC	SCIM 2.0
Is	login protocol	login protocol + verifiable token format	provisioning API
Era / format	2005, signed XML	2014, signed JWT (JSON)	2015, JSON REST
Runs when	a human logs in	a human logs in, or any API call carrying a token	on the IdP's sync schedule
Needs a browser	yes (assertion travels through it)	for login yes; for token verification no	no
Trust anchor	pre-exchanged signing certificate	published JWKS (public keys) fetched by URL	bearer token you issue to the IdP
Good for	web-app login with legacy/enterprise IdPs	web-app login and per-request identity on APIs/CLIs	lifecycle: create, update group membership, deprovision
Cannot do	identify API/CLI traffic	provision or deprovision anyone	log anyone in

What AxonFlow uses where

Surface	Standard	Since	Notes
Portal browser login	SAML or OIDC	SAML v9.15.0, OIDC v9.16.0	either protocol ends in the same portal session; configured per tenant
Per-user fleet identity (X-User-Token on governed API calls from tools like the Claude Code plugin)	OIDC verification only	-	stateless JWT verification against issuer/audience/JWKS; no browser involved
User provisioning + roles	SCIM 2.0	-	group-to-role mapping is the only role source, for every plane
Service-to-service / SDK auth	HTTP Basic (clientId/clientSecret)	-	machine traffic carries no human user; not an SSO surface at all
Portal fallback login	organization password	-	always available; the break-glass when SSO is down

Why both login protocols? Reach. Enterprise IdP estates split roughly into SAML-first (older Okta/ADFS/Entra deployments, common in regulated industries) and OIDC-first (JumpCloud, newer setups). Supporting both means the portal meets the customer's IdP where it is - while the fleet plane is OIDC-only, because only OIDC produces a token an API can verify statelessly.

The one wiring constraint: a tenant has ONE SSO configuration

AxonFlow stores a single SSO configuration per tenant, and it is either SAML or OIDC. Per-user fleet identity requires that configuration to be OIDC. Therefore a tenant using fleet identity must use OIDC for portal login too - one OIDC configuration then drives both (portal login uses the client credentials, fleet verification uses the audience). Configuring SAML portal login on such a tenant would replace the OIDC configuration and disable fleet identity. SCIM is a separate system and composes with either. Full reasoning: the three planes.

A complete enterprise setup, end to end

1. SCIM first - the directory and roles exist before anyone logs in.
2. OIDC portal login - humans reach the UI through the IdP; first-time users pick up their group-mapped role.
3. OIDC fleet tokens - every governed call a developer's tools make is attributed to that developer, with their SCIM-resolved role.
4. The organization password remains as break-glass, and Basic auth keeps carrying pure machine traffic.

Related docs

• Identity and Access Management overview - the three-planes model this page's mapping lives in
• Portal Login (SSO) - protocol flows and setup
• SCIM Provisioning and Group-to-Role Mapping
• Per-Developer Identity - the fleet plane in depth
• JumpCloud end-to-end - all three planes from one IdP