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.
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.
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 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.
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.
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.
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.
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.
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.
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.
