Sign-in tells you who someone is. This page is what they're allowed to do. The models behind the checks are in Authorization.
Pick a model for the environment
Each environment enforces one model. You choose it in the Authdog console:
- RBAC: roles hold permissions; seat-based. The default and simplest to reason about.
- ABAC: Rego attribute policies, evaluated at the edge.
- FGA: Zanzibar-style relationship tuples for fine-grained, resource-level access.
The rest of this page uses RBAC, because it covers most apps. All three models are enforced on the server.
Define roles and permissions
In the console, create permissions as specific capability strings (for example invoices:read and invoices:write) and group them into roles (admin, member, billing). A role is a named bundle of permissions.
Keep the permissions specific, and keep the role list small. Assignment stays simple, and the check on a route stays precise.
Assign roles to users
A user can receive a role two ways:
- Directly. Assign the role in the console or through the API.
- From an identity-provider group. Map the provider's groups to Authdog roles, so access is granted at sign-in. See Provisioning.
Organization membership is for account administrators under an organization. It doesn't grant end-user permissions inside an environment.
For enterprise customers, group mappings are the path we recommend. When they deprovision someone in their identity provider, access is revoked with no extra step on your side.
Enforce a check on a route
Roles and permissions travel on the validated session. On your backend, gate the route on the specific permission:
app.get("/invoices", requirePermission("invoices:read"), (req, res) => {
res.json(listInvoices());
});Always enforce this on the server. A check in the browser is for the interface only. It isn't a security boundary. See Backend requests to wire the gate into your framework.
ABAC and FGA alternatives
If RBAC is too coarse for your product:
- ABAC lets you write Rego policies over user, resource, and environment attributes. A typical rule is "editors can edit only their own region."
- FGA stores relationship tuples (
document:42#editor@user:alice) for per-object sharing, the way a document product shares a file. See FGA for the tuple model and current availability.
You configure both on the environment, and both are enforced on the server. See Authorization when you're choosing.
Whichever model the environment runs, an external service or gateway can ask Authdog for a decision over the AuthZEN Authorization API instead of rebuilding the check.
