Documentation
How Authaz is Built
Authaz is an authentication and authorization platform built around four principles: multi-tenant by design, authorization as a real engine (not a flag bag), cryptographic isolation per customer, and every modern auth method shipping in one coherent product. This page is a three-minute tour of how those principles show up in the architecture. Each section links to the deeper reference doc that proves the claim.
Components#
End users Your backend You (operator)
│ │ │
▼ ▼ ▼
┌───────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ Authaz Sign-In │ │ Management API │ │ Dashboard │
│ your-app.authaz.io│ │ your-app.authaz.io │ │ dashboard.authaz.io│
│ /oauth2/... │ │ /api/v1/... │ │ │
│ Hosted login UI + │ │ REST API for users │ │ Web admin console │
│ OAuth 2.0 server │ │ roles, tenants, │ │ for everything │
│ │ │ apps, audit logs │ │ above │
└───────────────────┘ └────────────────────┘ └────────────────────┘
Authaz Sign-In is the only component your end users see. The Management API is what your backend integrates with. The Dashboard is the web console you use to configure applications, roles, and tenants — under the hood, it's a thin layer over the same Management API.
Strengths#
Multi-tenant by design, not bolted on#
Most auth systems treat multi-tenancy as an enterprise add-on. Authaz treats it as the default shape of the world. Applications can run in three modes: single-tenant, multi-tenant with a shared user pool (where one user can belong to many tenants with different roles in each), or multi-tenant with isolated pools (where each tenant gets a fully separate user space). Tenant context is bound into every access token at authorization time and into every permission check at evaluation time — there is no "remember to filter by tenant" code path that can be forgotten.
Read the multi-tenancy guide →
Authorization is a Zanzibar-style engine#
Permissions in Authaz are evaluated by Zeratul, a relation-based authorization engine modeled on Google's Zanzibar paper. Permission checks resolve in sub-millisecond time. The same engine is the single source of truth for both user-issued tokens and machine-to-machine API keys — there is no parallel scopes-and-flags system that can drift out of sync. Roles support hierarchy and authority levels (so a tenant admin can't quietly grant themselves platform-level access), and assignments can be tenant-scoped or global.
Read the authorization guide →
Per-organization cryptographic isolation#
Every organization on Authaz has its own master encryption key, sitting inside a hierarchical envelope-encryption scheme rooted in a hardware-backed key service. To decrypt one organization's data, an attacker would need that organization's specific key chain — knowing another customer's key buys them nothing. Sensitive secrets (MFA seeds, OAuth client secrets, refresh tokens, API key material) are encrypted at rest with this hierarchy; passwords and similar credentials are hashed with bcrypt at a tuned work factor.
Read about tenancy customization →
Every modern auth method, one product#
Password and MFA, social sign-in (Google, Microsoft, Apple, GitHub), magic link, machine-to-machine credentials, and application-issued API keys — with passkey / WebAuthn and SAML 2.0 SSO landing soon. They're not separate products grafted together: they share the same user, role, and tenant model, and they all flow through the same Authaz Sign-In UI and the same OAuth 2.0 endpoints. Adding a new method to your application is a configuration change, not an integration project.
Read the authentication guide →
Modern OAuth 2.1 by default#
Authaz is a standards-compliant OAuth 2.1 + OpenID Connect authorization server. The OAuth 2.1 best-current-practice rules are not opt-ins — they're enforced: PKCE (S256) is required on every authorization-code flow, authorization codes are single-use, the implicit and resource-owner-password grants are not exposed at all, refresh tokens rotate on every exchange, and access tokens are short-lived RS256 JWTs verifiable through a per-application JWKS endpoint. Pushed Authorization Requests (PAR) and Demonstrating Proof of Possession (DPoP, RFC 9449) are supported for clients that want sender-constrained tokens. Algorithm choices are pinned in code so they cannot be downgraded by an attacker. See the flow diagram below.
Read the OAuth provider config → · Tokens reference →
How the protocols work#
OAuth 2.1 — Authorization Code with PKCE#
The default flow for web and mobile apps. The user authenticates at Authaz Sign-In, your app receives an opaque authorization code in the redirect, and your backend exchanges that code for tokens. PKCE binds the code to the originating client, so a stolen code is useless without the matching code_verifier.
Browser Authaz Sign-In Your backend
│ your-app.authaz.io │
│ │ │
│ ① redirect to /universal/oauth2/authorize │
│ with code_challenge (S256) + state + nonce │
├──────────────────────────▶│ │
│ │ │
│ ② hosted login page │
│ password / social / magic link / passkey │
│ + MFA if required │
│ + tenant pick if multi-tenant │
│◀─────────────────────────▶│ │
│ │ │
│ ③ 302 → {redirect_uri}?code=…&state=… │
│◀──────────────────────────┤ │
│ │ │
│ ④ GET {redirect_uri}?code=…&state=… │
├──────────────────────────────────────────────────────────▶│
│ │ │
│ │ ⑤ POST /universal/oauth2/token
│ │ grant_type=authorization_code
│ │ code=… code_verifier=… │
│ │◀─────────────────────────────┤
│ │ │
│ │ ⑥ { access_token (1h, RS256 JWT),
│ │ refresh_token (rotating),
│ │ id_token (OIDC) } │
│ ├─────────────────────────────▶│
│ │ │
│ ⑦ session cookie set; user signed in │
│◀──────────────────────────────────────────────────────────┤
Token signatures verify against https://your-app.authaz.io/.well-known/jwks.json. Refresh-token rotation, single-use codes, pinned RS256, and PKCE-S256 are all required by Authaz, not optional.
SAML 2.0 — SP-initiated SSO (coming soon)#
Used by enterprise customers who authenticate against their own identity provider. Authaz acts as the Service Provider (SP): Authaz Sign-In redirects the user to their IdP, receives a signed SAML assertion back, validates it, and then continues the same OAuth 2.1 flow above — so your app receives the standard tokens regardless of how the user authenticated.
Browser Authaz Sign-In Customer IdP Your backend
│ your-app.authaz.io (Okta / Entra / …) │
│ │ │ │
│ ① /universal/auth/saml/login │ │
│ (user picks SSO; routed by email domain) │ │
├──────────────────▶│ │ │
│ │ │ │
│ │ ② signed AuthnRequest │ │
│ 302 ───────────────────────────────────────▶ │
│ │ │ │
│ │ │ ③ user signs in at │
│ │ │ IdP (may already │
│ │ │ have an SSO │
│ │ │ session) │
│ │ │ │
│ ④ POST signed SAMLResponse to /universal/auth/saml/acs │
│◀──────────────────────────────────────────── │
│ │ │
│ ⑤ POST /universal/auth/saml/acs │
├──────────────────▶│ │
│ │ │
│ │ ⑥ verify XML signature, │
│ │ map IdP attributes → Authaz user, │
│ │ create-or-find user record │
│ │ │
│ ⑦ continue OAuth 2.1 authorization-code flow (③ onward, above) │
│◀──────────────────┤ │
The end result is the same set of tokens your app would have received from any other auth method — so SSO is a configuration concern for your customers, not an integration project for you.
What's outside this page#
This page is the hub. For depth, follow the links above, plus: authentication settings, tokens, and API reference. The setup walkthrough and the SDK quickstarts walk through the same architecture from a developer's first ten minutes.