Authentication and Authorization Defined: What's the Difference? [Infographic]

Authentication and authorization are two of the most confused terms in software security, and the confusion causes real bugs. They are different problems with different solutions, and most access-control failures come from running them together.

Authentication: who are you?

Authentication proves identity. The user (or service) presents credentials, and the system checks them against a known store. The output is a verified identity: a username, a user ID, a service principal.

The factors used are familiar:

• Something you know: password, PIN.
• Something you have: phone, security key, passkey.
• Something you are: fingerprint, face, voice.

Strong authentication combines two or more of these. The output is the same shape either way: "this request comes from user X."

Authorization: what are you allowed to do?

Authorization decides whether a verified identity is allowed to perform a specific action on a specific resource. It happens after authentication and depends on its output.

Common models:

• Role-based access control (RBAC). Users are assigned roles, roles have permissions.
• Attribute-based access control (ABAC). Decisions made from attributes of the user, resource, and context.
• Relationship-based access control (ReBAC). Decisions made from the graph of relationships between users and resources. Popularised by Google Zanzibar.
• Policy-based access control. Decisions expressed in a declarative policy language like OPA or Cedar.

The differences in plain language

• Order. Authentication runs first. Authorization runs after.
• Question. Authentication asks "who?". Authorization asks "can?".
• Output. Authentication outputs an identity. Authorization outputs allow or deny.
• Change frequency. Identity changes rarely. Permissions change often.
• Where it lives. Authentication is a session-establishment concern, usually at the edge. Authorization is a per-request concern at every endpoint.

Why mixing them up causes bugs

The most common access-control failure pattern: an endpoint checks that the user is logged in, and assumes that is enough. It is not. A logged-in user can still be the wrong user for this resource. Concrete examples:

• API returns any user's record if you change the ID in the URL.
• Admin panel reachable by anyone authenticated, because "only admins know the URL."
• File download endpoint streams any file if you know the path.

Every one of these is an authentication check standing in for an authorization check.

The discipline that prevents the bugs

• Deny by default. Every endpoint requires an explicit authorization decision.
• Check at the right layer. Object-level checks ("does this user own this object?") happen close to the data, not just in the controller.
• Externalise policy. Keep authorization rules out of business logic. Use a policy engine for non-trivial models.
• Audit every decision. Log who asked, what they asked for, and what was decided.
• Test the negative path. "Can a non-owner read this?" is the test most teams skip.

The bottom line

Authentication and authorization are different problems. Treat them that way. Build authentication once with strong factors, then enforce authorization explicitly at every endpoint that touches a resource. Most of the access-control breaches you read about would have been prevented by that one discipline.