Authentication & Authorisation
The Titan/Omnitron auth surface is split into four layers. Each layer is independently composable; the page you're reading next should be picked by what you're trying to do.
| If you want to… | Start here |
| Share roles and permissions between server and UI | Shared access policy |
| Verify a JWT and resolve a user | @titan-auth JWT primitives |
| Gate an RPC method on a role / permission / policy | @Auth decorator & PolicyEngine |
| Compose a permission string (grammar, wildcards, hierarchy) | Permissions |
| Grant a permission to a single user on top of their role | Per-user overrides |
| Apply attribute-based conditions (time window, MFA, IP) | ABAC conditions |
Project the auth context onto a @kysera/rls policy | RLS bridge |
| Capture every authorisation decision for audit | Audit trail |
| Get tokens to the client — cookies or bearer, and CSRF | Token issuance & transports |
| Understand how the four layers fit together | Mental model |
Migrate from @RequireRole(...) to permission strings | Migration: auth v1 → v2 |
Reading order for first-time integrators
Mental model — one page, one diagram, how roles / permissions / conditions / RLS combine.
Permissions — grammar, wildcards, hierarchical prefix grant. Read once, reference forever.
@titan-auth— set up the JWT verifier and the@Authdecorator.ABAC conditions when you need gates beyond role/permission (time of day, MFA-stepped-up, request IP, feature flag).
RLS bridge when your gates also need to apply at the database layer.
Audit trail when you need to prove, after the fact, that a decision was made the way it was.
Every page links back to the runnable examples in
recipes/api-service and
recipes/multi-tenant-saas.