Skip to content
OIDOT

Access control

Permissions, not a guessing game of role names.

Role-based access control built on permissions rather than hardcoded roles, fail-closed by design, with an admin console for managing it all.

Fail closed, by construction

Most role-based systems hardcode a handful of role names and hope every future requirement fits one of them. Oidot models roles as collections of permissions instead, so a new capability is a new permission, not a schema migration.

The default is denial: a permission that isn't explicitly granted is treated as absent, not as an edge case to handle later. An admin console sits on top for managing users, roles, and permissions without touching the database directly.

Features

Permission-based roles

Roles are named collections of permissions, not a fixed enum your code has to special-case.

Fail-closed by design

A missing or unrecognised permission denies access — it never silently allows it.

Admin console

Manage users, roles, and permissions, plus the OAuth clients your platform trusts.

Auditable changes

Admin actions are logged, so who changed what access is always reviewable.

Permission check flowA request is authorized only when its token carries the specific permission the endpoint requires.grantedmissingRequestToken permissionsPermission checkAllowedDenied (default)
system diagram: A request is authorized only when its token carries the specific permission the endpoint requires.

See the security model

Read how fail-closed access control fits into the platform's architecture.