RBAC & authentication

Two distinct auth surfaces:

1. Gateway (data plane) — virtual keys

Clients call /v1/* with a virtual key (Authorization: Bearer <key> or x-api-key). The gateway:

• looks the key up in the current snapshot
• checks the key’s model allow-list (empty = all)
• (roadmap) enforces budgets and RPM/TPM limits for the key’s scope chain

Keys are stored as hashes; the presented key is compared in constant time (rolter_auth::verify_key).

2. Control plane (dashboard) — users + roles

Human users authenticate to the control plane. v1 ships local accounts (argon2id password hashes). RBAC roles:

• admin — full control within scope (manage providers, routes, keys, members, budgets)
• member — create/edit routes and keys within scope
• viewer — read-only (dashboards, logs)

Roles are granted via memberships at an org / team / project scope. Permission checks resolve the most specific membership for the target resource.

flowchart LR
  U[User] -->|member of| Scope[org / team / project]
  Scope -->|role| Caps[admin / member / viewer]
  Caps --> Action{allowed?}

Roadmap

• OAuth2 / OIDC SSO — pluggable IdentityProvider; map IdP groups → roles.
• LDAP — bind + group mapping for enterprise directories.
• JWT service auth and short-lived tokens.
• Audit log surfaced in the UI.
• Optional constant-time map / pepper for virtual-key lookup hardening.