Authentication vs Authorization

These two words get mixed up constantly: in documentation, in code comments, and especially in system design interviews. They sound similar, they work together, and they're often implemented in the same layer of the stack. But they're fundamentally different concerns, and conflating them leads to real security bugs.

Here's the one-sentence version: Authentication answers "who are you?" and Authorization answers "what are you allowed to do?"

The Hotel Key Card Analogy

When you check into a hotel, you show your ID and credit card at the front desk. They verify you are who you claim to be. That's authentication.

The front desk then gives you a key card programmed to open room 412, and only room 412. Not the pool area after 10pm, not the executive lounge. That's authorization.

Your key card is the token that carries both pieces of information: proof of your identity, and a record of your permissions. The card reader at each door checks what you're allowed to do, not who you are.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Authentication (AuthN) and authorization (AuthZ) are complementary but distinct steps. Authentication happens first: the user proves who they are by presenting credentials. The auth service verifies them (bcrypt-compares the password hash, or validates an OAuth token from Google) and issues a signed token encoding the user's identity. On every subsequent request, the token is sent in the Authorization header. The protected resource (often via the API gateway) verifies the token signature — this is authentication again. Then it checks what the user is allowed to do — that's authorization. One without the other is incomplete.

1 / 10.5×1×2×3×Playground

AuthN identity flow — credentials verified, token issued

Authentication: Proving Identity

Authentication answers: "Is this request coming from who they claim to be?"

There are three fundamental factors of authentication:

• Something you know — Password, PIN, security question
• Something you have — Phone (for SMS/TOTP codes), hardware key (YubiKey)
• Something you are — Biometrics (Face ID, fingerprint)

Multi-factor authentication (MFA) combines two or more of these factors. A password alone is a single factor and can be phished, leaked, or brute-forced. Adding a TOTP code from an authenticator app means an attacker needs both your password and your phone.

Common Authentication Methods

Username/Password is the baseline. Passwords should be hashed (bcrypt, Argon2) before storage — never stored as plain text or with reversible encryption. A compromised database with properly hashed passwords is largely useless to an attacker.

OAuth 2.0 / OpenID Connect is the "Login with Google" flow. The user authenticates with an identity provider (Google, GitHub, Apple) that you trust. The provider sends your app a token confirming the user's identity. You never see the user's password — that's entirely the provider's problem. OpenID Connect (OIDC) is OAuth 2.0 with a standardized identity layer on top.

API Keys are long random strings issued to developers or services — simpler than OAuth for machine-to-machine communication. The downside: API keys are often long-lived and don't carry identity information natively, so you have to look them up in a database.

JWT (JSON Web Tokens) is a self-contained token that encodes user identity and can be verified without a database lookup. Covered in depth in the next chapter.

Passkeys (WebAuthn) are the modern replacement for passwords. The browser generates a public/private key pair; the private key never leaves the device. Authentication is a cryptographic challenge-response that can't be phished. Major platforms (Apple, Google, Microsoft) are pushing hard on passkeys and they're rapidly becoming standard.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Role-Based Access Control (RBAC) is the most common authorization model. Users are assigned roles, and roles carry a set of permissions. Alice has the Admin role — she can read, write, delete posts, and manage users. Bob has the Editor role — he can read and write, but not delete. When Alice makes a DELETE request, the authorization check passes. When Bob makes the same request, it's rejected with 403 Forbidden (not 401 — he's authenticated, just not authorized). RBAC is simple to reason about and easy to audit. It breaks down when you need fine-grained policies like "Editor but not for financial documents" — that's when ABAC (attribute-based) becomes necessary.

1 / 10.5×1×2×3×Playground

RBAC user-role-permission model — Alice→Admin→permissions

Authorization: Controlling Access

Once you know who the user is, you need to decide what they can do. This is authorization.

The three dominant authorization models:

RBAC — Role-Based Access Control

Users are assigned roles. Roles have permissions. A user inherits all permissions of their assigned roles.

RBAC is simple to understand, easy to audit, and works well when your permission needs map naturally onto a small set of distinct roles. It's the model used by most SaaS products (Free, Pro, Admin).

Where it breaks: Role explosion. When you start creating roles like "Admin-but-not-in-Europe" or "Editor-except-for-financial-reports", you've outgrown RBAC.

ABAC — Attribute-Based Access Control

Instead of roles, access decisions are based on attributes of the user, the resource, and the environment. Policies evaluate to allow/deny.

ABAC is extremely powerful and expressive — you can encode very complex access rules. It's the foundation of AWS IAM policies.

The tradeoff: Harder to reason about and audit. "Why can Alice access this?" requires evaluating potentially many policy rules rather than just looking up a role.

ACL — Access Control Lists

An ACL is a list attached to a resource specifying which users or groups can access it and with what permissions.

You've seen this in Google Docs ("Anyone with the link can view") and Unix file permissions (chmod 755). ACLs are intuitive and direct, but they can become hard to manage at scale — updating permissions for 10,000 files when an employee leaves is painful.

Hybrid Approaches

Real systems rarely use just one model. A typical SaaS app might use RBAC for coarse-grained access (free vs. paid features), ABAC for environment-based controls (region restrictions, time-based access), and ACLs for resource-level sharing (share this specific document with this specific person).

Where Auth Lives in a System

Authentication typically lives at the API gateway or in a dedicated auth service. The gateway verifies the token/session and rejects unauthenticated requests before they reach backend services.

Authorization can live at multiple layers. The gateway handles coarse-grained checks: is this API key allowed to hit this endpoint at all? Individual services handle fine-grained checks — can this user access this specific record?

The database is the last line of defense — row-level security (supported by PostgreSQL) can enforce authorization at the data layer, preventing even application bugs from leaking data across tenants.

Summary

Authentication and authorization are complementary but distinct:

• Authentication = proving identity (login, tokens, OAuth)
• Authorization = enforcing permissions (RBAC, ABAC, ACLs)

One without the other is incomplete. Solid authentication with broken authorization still exposes data to the wrong users. Sophisticated access control collapses the moment authentication is weak enough for an attacker to impersonate any user.

Build auth correctly from the start — retrofitting it into an existing system is one of the most painful engineering tasks there is.