Three words people blur together, separated cleanly. Send a request through two gates — Authentication (who are you?) then Authorization (are you allowed?) — and see RBAC as the mechanism that decides the second. Watch a valid login still get denied the wrong action.
Set the token, the user's role and the action, then send the request through the two gates. The headline moment: a valid login can still be forbidden the wrong action.
Token (authentication)
Role
Requested action
📨
request
→
🔑
Authentication
who are you?
→
🛡️
Authorization (RBAC)
are you allowed?
→
📦
resource
🔑 Authentication
Who are you?
Login, validated JWT, MFA. Proves identity. → 401 if it fails.
🛡️ Authorization
Are you allowed?
A separate decision per action/resource. → 403 if denied, even when logged in.
📋 RBAC
How authz decides
Roles → permissions. The mechanism that turns 'who' into 'allowed or not'.
What just happened
▹Authentication answers 'who are you?' — proven by a login, a validated token, MFA. It's the first gate; fail it and you get 401 and nothing else runs.
▹Authorization answers 'are you allowed to do THIS?' — a separate decision made after you're identified. A perfectly valid login can still be denied an action it has no right to (403). Authentication is not permission.
▹RBAC is one way to make the authorization decision: map each role to a set of permissions, then check the user's role against the action. AuthN identifies the role; RBAC uses the role to allow or deny.