"Who are you?" is a completely different question from "what can you do?" — and mixing them up is one of the most common access-control mistakes in software.
The two terms get used almost interchangeably in casual conversation — "auth" covers both, most login forms handle both in the same flow, and plenty of API middleware even bundles both into one function called checkAuth(). That convenience hides a real distinction: authentication and authorization are two separate decisions, answering two separate questions, and a system that quietly collapses them into one is exactly the kind of system where broken access control shows up.
Authentication (AuthN) verifies who a user or system actually is — confirming that an identity claim is genuine, typically via something they know (a password), something they have (a certificate, a hardware token, an MFA code), or something they are (a biometric). The output of a successful authentication is exactly one thing: a confirmed identity — "this really is user Jane." Nothing more. Authorization (AuthZ) is a completely separate question, asked after authentication has already succeeded: given that this identity is confirmed, what is it allowed to do? Which resources, which actions, which data? That decision is based entirely on the permissions, roles, or policies assigned to that identity — never on how convincingly that identity proved who it was. A perfect, MFA-backed login proves identity with total confidence and still says absolutely nothing about what that identity is permitted to touch.
Once authentication succeeds, the system has one fact: a confirmed identity, usually carried forward as a session cookie or a bearer token. That fact never expands on its own. Every time that identity tries to do something — open a page, call an API, read a record, click delete — the system is supposed to run a fresh, independent authorization decision: look up the roles, permissions, or policies (RBAC roles, ABAC attributes, an access-control list, a policy engine) attached to that identity, and check them against the specific resource or action being requested right now. The two checks even tend to fail differently: a broken authentication check lets an impostor in as someone else; a broken authorization check lets a real, verifieduser reach something they were never supposed to touch. The second failure mode is arguably more common in production software, precisely because it's so tempting to treat "logged in" as if it already answered the permissions question.
This is false, and it's not a harmless simplification — it's a real, common access-control security flaw. A successful authentication only confirms identity. It says absolutely nothing about what that confirmed identity is actually permitted to do, which is a completely separate authorization decision that must be checked independently for every specific resource and action, never assumed to follow automatically from a successful login. A legitimate, MFA-verified employee trying to open another department's confidential files, or a properly logged-in user without admin rights trying to reach an admin panel, should both be denied— not because the system doubts who they are, but because who they are simply isn't authorized for that specific thing. Systems that skip or weaken this separate authorization check — treating "authenticated" as equivalent to "authorized for everything," often by forgetting to re-check permissions on a specific route, API endpoint, or object ID — are exactly the pattern behind privilege-escalation and broken-access-control vulnerabilities, including insecure direct object references and missing function-level access control.
Explains why authentication (confirming WHO a user is) and authorization (deciding WHAT that confirmed identity is allowed to do) are two independent, sequential decisions rather than one combined check — and why treating a successful login as automatic permission for everything is a common, serious access-control vulnerability.
Both terms get shortened to "auth," both usually happen within the same login flow, and a lot of framework middleware even bundles them into a single function or decorator. That convenience obscures a real boundary: authentication answers "who is this," authorization answers "what can they do," and a confirmed identity from the first question carries zero information about the answer to the second. Conflating them — assuming that passing authentication is equivalent to passing every future authorization check — is one of the most common root causes of broken access control.
Authentication happens once, at login: credentials (password, certificate, biometric, MFA token) are verified against a known identity, and on success the system issues a session or token that carries that confirmed identity forward. Authorization happens separately, and repeatedly: on every subsequent request, the system is supposed to take the confirmed identity from that session/token and check it against the permissions, roles, or policies assigned to it — RBAC roles, ABAC attributes, an access-control list, or a policy engine decision — for that specific resource or action being requested right now. Authentication runs once; authorization runs continuously, for the lifetime of the session.
The two checks fail in different, instructive ways. A broken authentication check lets an impostor in as someone else entirely. A broken authorization check lets a genuinely real, correctly verified user reach something they were never supposed to touch — a horizontal privilege escalation (another user's data) or a vertical one (a regular user reaching an admin function). This second failure mode — commonly appearing as insecure direct object references or missing function-level access control — is one of the most frequently reported classes of real-world web application vulnerabilities, and it almost always traces back to a developer checking "is this user logged in?" instead of "is this specific logged-in user allowed to do this specific thing?"
No. Authentication only confirms identity — it establishes that the system correctly knows who the user is. What that confirmed identity is permitted to do is a completely separate authorization decision, checked independently against that identity's specific permissions, roles, or policies for every resource and action. Assuming login implies blanket access is a common and serious access-control flaw.
Yes, and this is the normal, correct behavior of a properly designed system, not an error. A legitimate, verified employee can be correctly denied access to another department's files, or a properly logged-in user without admin rights can be correctly denied entry to an admin panel — both because authorization, a separate check based on that identity's permissions, failed, even though authentication succeeded perfectly.
In a correctly designed system, on every single request that touches a protected resource or action — not once at login. Authentication typically runs once and issues a session or token; authorization must be re-evaluated independently for each subsequent page view, API call, or action, since permissions can be scoped to specific resources that vary request by request.
Treating "authenticated" as equivalent to "authorized for everything" is a textbook broken access control vulnerability. It typically appears as missing function-level access control (a regular authenticated user reaching an admin-only endpoint because only login status was checked) or insecure direct object references (an authenticated user changing an ID in a URL or request to access another user's data because ownership/permission was never separately verified).
Multi-factor authentication (MFA) strengthens the authentication side — making the identity-verification step harder to defeat. Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) are both authorization models — frameworks for deciding, after identity is already confirmed, what a given role or set of attributes is permitted to do. Stronger MFA never substitutes for a correctly enforced RBAC/ABAC authorization check, since they answer different questions.
Try our Cybersecurity Studio
More calculators, simulators, and guides for this discipline.