Identity & Access Management
AxonFlow has two distinct identity stories, and keeping them separate makes the docs much easier to trust:
- application and SDK authentication for programmatic access to the runtime
- enterprise user identity and provisioning for browser access, admin workflows, and organization-scale operations
Community and Public Runtime Authentication
Community users authenticate programmatically using Basic auth with a clientId and clientSecret pair. Every SDK request to the Agent gateway includes an Authorization: Basic header containing the Base64-encoded credentials. The Agent validates these credentials, resolves the tenant context, and forwards the request into the policy enforcement pipeline.
This model is the right fit for:
- backend services calling the Agent gateway
- local development and self-hosted testing
- framework integrations (LangChain, LangGraph, CrewAI, and others)
- automation and service-to-service traffic
- any scenario where a machine, not a human in a browser, is the caller
Client credentials are scoped to a single tenant. Each credential pair maps to exactly one clientId (which also serves as the tenant identifier), so multi-tenant deployments use separate credential pairs per tenant. There is no browser session, no cookie, and no redirect involved. The entire authentication exchange happens in a single HTTP request header.
The DEPLOYMENT_MODE environment variable determines how strictly credentials are enforced:
| Mode | Auth Behavior |
|---|---|
community | Optional. Requests without credentials are accepted with a default tenant context. |
eval | Required. Requests without valid Authorization: Basic credentials receive HTTP 401. |
enterprise | Required. Same enforcement as eval, plus SSO and SCIM for portal access. |
If you are integrating AxonFlow into an application, start with SDK Authentication.
Enterprise Identity Features
Enterprise adds the browser and organization-identity layer that larger companies usually need:
- Single Sign-On (SSO) for portal login through a corporate identity provider
- SAML 2.0 as the protocol layer for assertion-based authentication
- OIDC (OpenID Connect) as an alternative protocol for providers that prefer it
- SCIM 2.0 provisioning for automated user lifecycle management
These capabilities matter when AxonFlow is no longer used by just one engineering team and instead needs to fit into a company’s broader identity, access-review, and user-lifecycle processes.
When Identity Features Become Important
Teams often start in community with service credentials and direct API integration. The shift toward enterprise identity usually happens at one of these inflection points:
- Multiple human users need portal access. Once operations staff, compliance reviewers, or approvers need to log into the AxonFlow portal, managing separate credentials per person becomes impractical. SSO lets them authenticate through the corporate IdP they already use.
- Corporate IdP integration is required. Security teams often mandate that all internal tools federate authentication through the organization’s identity provider (Okta, Azure AD, Auth0, or similar). SSO with SAML 2.0 or OIDC satisfies this requirement.
- Automated onboarding and offboarding. When employees join, move teams, or leave the company, their AxonFlow access should follow the same lifecycle. SCIM provisioning automates this so that IdP group changes propagate to AxonFlow roles without manual intervention.
- Access reviews and compliance audits. Formal access-review processes require a clear record of who has access, when it was granted, and how it maps to organizational roles. SCIM-managed provisioning with IdP-sourced group memberships provides this automatically.
Choosing the Right Identity Approach
| If you need... | Use this |
|---|---|
| Programmatic SDK or API access | Basic auth with clientId/clientSecret (SDK Authentication) |
| Browser-based portal login for teams | SSO with SAML 2.0 or OIDC |
| Federated authentication through a corporate IdP | SAML (most enterprise IdPs) or OIDC (for providers that prefer it) |
| Automated user provisioning and deprovisioning | SCIM 2.0 |
| IdP group memberships mapped to AxonFlow roles | SCIM group-to-role sync |
| Full enterprise identity lifecycle | SSO + SAML/OIDC + SCIM together |
SDK authentication and enterprise identity are complementary, not mutually exclusive. In a typical enterprise deployment, backend services continue to use Basic auth with client credentials while human users access the portal through SSO.
Supported Protocols and Providers
AxonFlow supports two authentication protocols for enterprise SSO:
- SAML 2.0 is the primary protocol and is supported by virtually all enterprise identity providers. It uses XML-based assertions and is the most common choice for portal authentication.
- OIDC (OpenID Connect) is supported as an alternative for providers or organizations that prefer token-based authentication over SAML assertions.
For user provisioning, AxonFlow implements SCIM 2.0 per RFC 7643 (Schema) and RFC 7644 (Protocol), with dedicated provider adapters for Okta, Azure AD (Entra ID), and Auth0. Any SCIM 2.0 compliant provider can integrate through the standard endpoints.
