1. 01

   Integrate once, replace the provider later

   Your applications hold one client registration against one issuer. Changing which identity provider stands behind it is a change in the tenant, not a release in every application you own.

2. 02

   A schema per tenant, not a tenant column

   Isolation enforced by PostgreSQL rather than by remembering a WHERE clause. Each tenant is its own schema, its own issuer, its own key set and its own branded sign-in.

3. 03

   Roles as a graph, with scopes that combine

   A role can have several parents, and the assignment that matters is usually a slice: this region, that category. Values of one type are alternatives, values of different types combine, and the result is computed at every token issuance.

4. 04

   Per-resource access, managed by your own application

   Resource Authorization gives your applications the same role engine over their own objects, projects, workspaces or documents, through machine-to-machine APIs. No second authorization cluster, and no directory to keep in sync with it.

5. 05

   Application trust you can read in one line

   One registration and one secret per application. Letting one application call another is adding an audience to a list, checked when the token is minted and again at the edge, so the graph of who may call whom is a thing you can read rather than infer.

6. 06

   Machines as their own identity type

   Agents, service accounts and devices are identity types under the same authorization model as people, with certificates from a built-in authority, delegated tokens that name their audience, and a colour in the console that means a machine is holding this.

7. 07

   Authentication that happens before your code runs

   The gateway verifies the signature, enforces the path rules, manages the browser session and mints a per-application token from one sign-in. Certificates for automatic-issuance authorities renew themselves, and a replayed refresh token takes its whole family down with it.