Axowl as your identity platform & federation hub
Every standard. Both directions. One sealed core.
Axowl speaks OAuth 2.0, OpenID Connect, SAML 2.0, SCIM, and FIDO2 — as the provider your apps and partners federate into, and as the relying party that accepts the IdP you already run. Same protocols every incumbent supports, on a hardware-rooted, tamper-evident core they structurally cannot match.
2-way
provider + relying party
issue into apps · accept your IdP
open standards, natively
OAuth2 · OIDC · SAML 2.0 · SCIM · FIDO2
shared secrets to steal
RS256 + JWKS · public-key verification
Talk to sales Read the docs
OAuth 2.0 OIDC
Authorization server + federation Auth Code + PKCE · discovery by Authority alone
SAML 2.0
Service Provider + Identity Provider SP- and IdP-initiated · signed assertions
SCIM 2.0
Automated user provisioning create · update · deprovision on the directory event
FIDO2
Multi-browser passkeys WebAuthn · platform authenticator · phishing-resistant
Federation, both directions
Accept any IdP. Become the IdP. Same platform.
Most identity products do one direction well. Axowl does both, for both protocols — so the enterprise IdP you already run keeps working, and the apps and partners downstream of you sign in with Axowl.
Inbound · accept
Axowl as Relying Party / SP
Bring your own IdP. Your users sign in with it.
Your workforce authenticates through the identity provider you already run. Axowl federates in over OpenID Connect (Okta, Entra ID, Google, any OIDC IdP) or SAML 2.0 (ADFS, Ping, any SAML IdP), validates the assertion, and provisions the user just-in-time.
OIDC federation: Okta · Entra ID · Google · custom
SAML 2.0: metadata exchange or manual, attribute mapping
Just-in-time provisioning on first sign-in
No password ever stored — your IdP stays the source of truth
Outbound · issue
Axowl as Provider / IdP
Your apps and partners sign in with Axowl.
Axowl is a full OAuth 2.0 / OIDC authorization server and SAML 2.0 identity provider . Your own apps, partner sites, CLI tools, and legacy systems integrate as registered clients — by Authority alone, no custom SDK required.
OIDC: Authorization Code + PKCE, refresh, userinfo, discovery
SAML 2.0 IdP: SP- and IdP-initiated SSO, signed assertions
Per-client config: redirect URIs, scopes, grant types, PKCE
RP-initiated logout with post-logout redirect validation
Integrate: Point Authority at your org issuer · zero shared secret
OAuth 2.0 · OpenID Connect
A standard authorization server. Per-client by design.
Any off-the-shelf OIDC client points its Authority at your org issuer, runs discovery, and performs a full login — Authorization Code + PKCE, refresh tokens, UserInfo. Each application is its own OAuth client, configured the way the RFC defines it: redirect URIs, scopes, grant types, and PKCE per client.
Per-client OAuth config
Application = one OAuth client
Redirect URIs, allowed scopes, grant types, PKCE requirement, and post-logout redirects are set on each application — the RFC 7591 client metadata model, the same shape Auth0, Okta, and Cognito use.
What it gives you
Least privilege per integration
A leaked client cannot redirect tokens anywhere it likes, request scopes it was never granted, or use a grant it was never allowed. Each client is boxed to exactly what it needs.
PKCE-first
Public clients, no secret
SPAs, mobile, and CLI tools authenticate with PKCE (S256) instead of a long-lived client secret. Confidential clients can still use a secret when they need one.
What it removes
A secret to leak
No shared secret shipped in a mobile binary or single-page app. Nothing in the browser bundle an attacker can lift and replay.
SAML 2.0
The enterprise protocol, both ends covered.
SAML is still how large enterprises do SSO. Axowl is a Service Provider so your workforce signs in through an existing SAML IdP, and a SAML Identity Provider so downstream apps can sign in with Axowl. SP-initiated and IdP-initiated flows, signed assertions, and attribute-to-profile mapping.
SAML SP
Inbound SSO
Your SAML IdP logs your people in.
Connect ADFS, Ping, or any SAML 2.0 IdP by metadata URL or manual entry. Axowl verifies the assertion signature against your IdP certificate, maps attributes to a profile, and provisions just-in-time.
Metadata exchange or manual endpoint + certificate
Signature validation on every assertion
Attribute mapping → JIT profile
SAML IdP
Outbound SSO
Downstream apps sign in with Axowl.
Axowl issues signed SAML assertions so SaaS apps and internal systems that only speak SAML can use Axowl as their identity provider — alongside the same apps you wire over OIDC.
SP-initiated and IdP-initiated SSO
Signed assertions on your org signing key
One identity core for both SAML and OIDC consumers
FIDO2 · WebAuthn
Passkeys that aren't trapped in one browser.
A passkey created in one browser's password manager is often useless in the next. Axowl binds passkeys to the device's platform authenticator — Windows Hello, Touch ID, the TPM and Secure Enclave themselves — so one enrolled device works across every browser on it. Credentials are managed at the account level, so enrolling more devices is one step, not a migration.
Platform-bound, browser-free
One device, every browser
The credential lives in the OS authenticator (TPM / Secure Enclave), not a single browser's vault. Chrome, Edge, Firefox, Safari on that device all use the same passkey.
What it removes
"It won't work in my other browser"
No re-enrollment per browser, no lockout when a user switches. The single biggest reason passkey rollouts stall, gone.
Account-level credentials
Enroll many, manage in one place
Passkeys, security keys, and devices are managed per account. Add a laptop or a phone, revoke a lost one — without touching the others.
What it gives you
Phishing-resistant, recoverable
WebAuthn origin binding makes credentials unphishable, and multi-device enrollment means losing one is an inconvenience, not a lockout.
Why ours is stronger
Everyone supports the standards. We implement them on hardware.
Protocol support is table stakes. The difference is the core underneath — keyless verification, a sealed login history, and signing keys that derive in silicon and never leave it.
Where we go further
Same protocols. A core they can't copy.
Capability
Axowl
Typical IDaaS
Typical OSS IdP
✓ native · △ partial / add-on · ✕ out of scope Comparison reflects general capabilities of each product category, not specific commercial offerings.
Standards on the outside. Hardware on the inside.
Wire Axowl into your stack with the protocols you already use — and get a sealed, keyless, hardware-rooted core no incumbent can retrofit.
Talk to sales Back to Enterprise