Authentication Is Not Authorization
Authentication is proving which identity is making a request; authorization is deciding what that identity is allowed to do. A valid login, session, token, or password check should never be treated as permission to read, change, invite, approve, delete, or administer anything without a separate access decision.
This distinction matters because many security bugs start as a shortcut: the application checks that a request came from a real account, then assumes the account may perform the requested action. That collapses “known user” into “permitted user”. In multi-tenant products, collaboration tools, billing systems, admin consoles, and organisation features, that mistake can expose another customer’s data or give ordinary users powers meant for a narrower group.
Concretely, authentication usually runs near the edge of the system: verify credentials, validate a session, parse a signed token, and attach an identity to the request. Authorization runs at the point of action. It asks whether this subject may perform this action on this object, using a model such as RBAC for named roles, ABAC for user, resource, request, or environment attributes, or ReBAC for relationships like membership, ownership, hierarchy, sharing, and delegation.
The trade-off is that richer permission models are harder to operate. RBAC is simple when product rules match roles, but it becomes awkward when access depends on resource properties or context. ABAC can express those conditions, but needs reliable attributes and clear policy evaluation. ReBAC handles connected products well, but brings graph-shaped data, harder explanations, and more edge cases. The honest answer is not “use the most fine-grained model”; it depends on what facts the rule needs.
Engineers meet this boundary in route handlers, service methods, database query filters, background jobs, API gateways, admin tools, and policy engines. A common pattern is to authenticate once, then pass the identity and request context into explicit authorization checks close to protected operations. Good reviews ask not only “is the user logged in?” but “why is this identity allowed to do this action to this particular resource?”
Common questions
- Is a JWT or session cookie enough for authorization?
- No. A token or cookie usually proves that authentication happened and may carry useful claims, but it does not by itself answer every permission question. The application still needs to check whether the authenticated identity may perform the requested action on the specific resource, using current roles, attributes, or relationships.
- How do RBAC, ABAC, and ReBAC relate to this distinction?
- They are authorization models, not authentication methods. RBAC decides from assigned roles, ABAC decides from attributes of the subject, object, action, or context, and ReBAC decides from relationships between entities. Authentication supplies the identity that these models reason about; it does not replace the policy decision.
- Which authorization model should a product start with?
- Start with the simplest model that can express the product’s real rules. If roles are enough, use RBAC. If decisions depend on properties such as department, plan, classification, or region, use ABAC. If access depends on membership, ownership, sharing, hierarchy, or delegation between objects, use ReBAC.