Authentication vs authorization
- Written for
- + Written for
- Deprecated
- + Deprecated
- Applies to
- + Applies to
Authentication vs authorization
Two words that sound alike and do very different jobs. Atlas handles both, but it helps to keep them straight.
Authentication — who are you?
Authentication proves identity. It's the sign-in flow: a user presents an identifier and a factor (password, code, passkey, social login), and Atlas confirms they are who they claim to be, then issues a session. Everything in Sign-in methods is authentication.
Authorization — what may you do?
Authorization decides permissions after a user is authenticated. Atlas gives you two complementary systems:
1. Roles & permissions (RBAC)
Within an organization, users hold roles (like org:admin) that bundle permissions (like org:members:manage). You check them on the server and in your UI:
Server:
has({ permission: 'org:members:manage' })orprotect().UI: wrap privileged interface in
<Protect>.
Roles and permissions ride inside the verified session token, so checks are fast and offline. See Roles & permissions.
2. Fine-grained access (FGA)
For per-object relationships — "Ada can edit document 42" — Atlas offers a Zanzibar / OpenFGA-style relationship model. Use it when access depends on the specific resource, not just a global role.
Putting them together
Authentication → a verified session (who)
Authorization → roles / permissions / relationships (what)A typical request: verify the session (authentication), read the user id and roles from the token, then check whether those roles grant the permission this endpoint requires (authorization).
Next
See the full menu of ways users can prove who they are → Sign-in methods overview.