Skip to main content

Single Sign-On (SSO)

Single sign-on is an enterprise capability for teams that need browser-based access to AxonFlow through their existing identity provider.

What SSO Solves​

SSO matters when AxonFlow is used by more than one or two engineers and starts to involve:

  • operations teams
  • compliance reviewers
  • platform administrators
  • approvers and stakeholders who need portal access

Instead of managing separate user credentials in AxonFlow, organizations can authenticate those users through their existing identity provider.

What It Looks Like in Practice​

With enterprise SSO enabled:

  1. a user starts from the AxonFlow portal or login flow
  2. AxonFlow redirects the user to the company identity provider
  3. the identity provider authenticates the user
  4. AxonFlow creates an authenticated portal session

This is different from SDK or service-to-service authentication, which remains the right model for application traffic.

Why Teams Upgrade for SSO​

SSO is often one of the first enterprise requirements raised by:

  • security teams
  • IT administrators
  • compliance reviewers
  • platform teams standardizing internal access

It helps with:

  • centralized authentication policy
  • MFA enforcement through the existing identity provider
  • faster onboarding and offboarding
  • cleaner audit posture for internal reviews

Supported Protocols​

AxonFlow Enterprise SSO supports two authentication protocols:

  • SAML 2.0 is the primary protocol, supported by virtually all enterprise identity providers. It provides the assertion and attribute mapping model needed for portal session creation and is the most common choice for enterprise SSO deployments.
  • OIDC (OpenID Connect) is supported as an alternative protocol for organizations that prefer token-based authentication. OIDC uses ID tokens and standard OAuth 2.0 flows rather than XML assertions.

The SSO implementation supports the following identity providers with provider-specific configuration:

  • Okta -- domain-based configuration, the most common enterprise IdP (SAML or OIDC)
  • Azure AD (Entra ID) -- tenant ID and application ID configuration for Microsoft environments (SAML or OIDC)
  • Auth0 -- domain-based configuration (SAML or OIDC)
  • Custom SAML -- any SAML 2.0 compliant provider via manual metadata configuration
  • Custom OIDC -- any OpenID Connect compliant provider via issuer URL and client credentials

Each provider configuration stores the entity ID, SSO URL, SLO (single logout) URL, ACS (assertion consumer service) URL, and the IdP's X.509 certificate for signature verification. For OIDC providers, the configuration stores the issuer URL, client ID, client secret, and redirect URI instead.

SSO Flow in Detail​

The authentication flow works as follows:

  1. A user navigates to the AxonFlow portal login page.
  2. The portal identifies the user's tenant (typically by email domain or subdomain).
  3. AxonFlow generates a SAML AuthnRequest and redirects the browser to the tenant's configured IdP.
  4. The IdP authenticates the user (password, MFA, or whatever the IdP requires).
  5. The IdP posts a signed SAML Response back to AxonFlow's ACS endpoint.
  6. AxonFlow validates the SAML assertion signature, extracts user attributes, and creates a portal session.

AxonFlow also supports IdP metadata fetch via POST /api/v1/sso/fetch-metadata, which retrieves and parses metadata from a provider's metadata URL. This simplifies setup because administrators can paste a metadata URL instead of manually entering entity ID, SSO URL, and certificate values.

HTTPS required

The metadata URL must use HTTPS. URLs that use plain HTTP or resolve to private/internal IP addresses (e.g., 10.x.x.x, 127.0.0.1, 169.254.x.x) are rejected as part of SSRF protection. Ensure your IdP metadata endpoint is publicly accessible over TLS.

How SSO Integrates with AxonFlow Sessions​

SSO is a portal authentication mechanism. It controls who can log into the AxonFlow customer portal and admin workflows. It does not affect SDK or service-to-service authentication, which continues to use API keys and client credentials.

Once authenticated through SSO, the user's portal session carries the tenant context, role assignments, and permissions needed for portal operations like policy management, approval workflows, audit review, and provider configuration.

If SCIM provisioning is also configured, user accounts and group memberships are managed automatically by the IdP, so the SSO-authenticated user always has the correct role assignments without manual portal administration.

Public vs Protected Documentation​

This public page explains when you need SSO and how it fits into the product story. The protected enterprise docs cover the actual setup flows, provider-specific instructions, and admin procedures.

Last updated on