Authentication & Authorisation
Design RFC
The roles + permissions + ABAC + RLS-bridge stack documented in this section is an in-progress architectural target. The current Omnitron build ships only the base auth surface — JWT issuance, session lifecycle, and a single admin role (see OmnitronAuth in services-reference). Treat these pages as the design reference, not a feature you can flip on today.
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 |
|---|---|
| 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 |
| 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.