Authentication vs Authorization

Authentication is who you are. Authorization is what you can do. Confusing them is one of the most common security bugs in real systems, so let's nail the difference and how each is implemented.

Two questions, often confused

Authentication answers "who are you?". Authorization answers "are you allowed to do this?". They sound similar and people abbreviate them as authn and authz, which makes the confusion worse. Most security incidents I have seen come from a system that authenticates correctly but authorizes incorrectly. The user proves they are user 42, then the system happily lets user 42 read user 100's data because it forgot to check ownership.

The mental model: at the front door, a bouncer checks your ID. That is authentication. Inside the club, a server checks if your wristband says VIP before letting you upstairs. That is authorization. You can be authenticated but unauthorized. You can not be authorized without first being authenticated (usually).

How authentication works

The user proves identity by presenting one or more of: something they know (password, PIN), something they have (phone, hardware key), something they are (fingerprint, face). Multi-factor authentication combines at least two. The classic flow is: user submits credentials to the auth server, server verifies, server issues a token (session cookie or JWT), client sends the token on subsequent requests.

Passwords should never be stored in plain text. Hash them with a slow function like bcrypt, scrypt, or argon2, with a per-user salt. Never roll your own. Use a vetted library.

How authorization works

Two main models you will encounter.

RBAC (Role-Based Access Control)

Users are assigned roles like "admin", "editor", "viewer". Each role has a set of permissions. Easy to reason about, easy to audit, scales well to organizations. The downside is roles tend to multiply ("editor", "editor-with-publishing", "editor-but-not-finance") until you have hundreds of them.

ABAC (Attribute-Based Access Control)

Decisions are made based on attributes of the user, the resource, and the environment. "User can edit document if document.owner_id equals user.id and user.department equals document.department and current_time is during business hours." More flexible but harder to reason about.

Most real systems combine both. Roles for coarse-grained access, attribute checks for ownership and context.

The most common security bug

IDOR. Insecure Direct Object Reference. The endpoint GET /api/orders/12345 authenticates the user but forgets to check that order 12345 actually belongs to them. Now anyone with a valid login can read anyone else's data by changing the URL. The fix is simple but easy to forget: every read or write of a resource needs to verify the requesting user owns it (or has a role that grants cross-user access).