Authentication vs. Authorization: Who You Are vs. What You Can Do

WHY IT EXISTS: To solve the fundamental problem of securing digital resources. Without a way to verify who is asking for data and what they are allowed to see or change, any system with multiple users or different levels of access would be chaotic and insecure. These concepts create a structured framework for managing access control.

THE MENTAL MODEL: Think of a secure office building. Authentication is the front desk guard checking your photo ID to verify you are who you say you are and that you work there. Authorization is the keycard you're given. Your keycard opens the main door and your personal office, but it won't open the CEO's office or the server room. Authentication gets you in the building; authorization determines which doors you can open inside.

HOW IT WORKS: The process is sequential. First, a user presents credentials (like a username and password) to prove their identity. The system validates these credentials. If successful, the user is authenticated, and the system typically issues a temporary proof of identity, like a session token or a JWT. For every subsequent action that requires permissions, authorization occurs. The system checks the user's identity token against an access control list (ACL) or role-based rules for the requested resource. Access is granted or denied based on whether that identity has the required permissions.

WHEN TO USE IT: Use this two-step process in any system where users have accounts or where different levels of access are required. This applies to almost all modern applications: social media apps where you can only edit your own profile, e-commerce sites where only store owners can add products, and company dashboards where only managers can see financial reports.

WHEN NOT TO USE IT: The full process is unnecessary for completely public, read-only content, like a marketing homepage or a public blog post. If there is no concept of a user account, private data, or protected actions, there is nothing to authenticate or authorize access to. The moment you add a login button or a members-only area, you need both.

ONE CANONICAL EXAMPLE: In an Express.js app, a user logs in. The /login route handler performs authentication by checking their password hash. If it's correct, it generates a JSON Web Token (JWT) containing the user's ID and role (e.g., 'user'). When that user tries to access /api/admin/dashboard, a middleware function first verifies the JWT is valid (authentication). Then, it inspects the token's payload, sees the role is 'user', not 'admin', and denies the request (authorization).