Authentication vs Authorization: A Clear Explanation for Developers

If you have been in engineering long enough, you have probably heard "auth" used to mean two different things in the same conversation. Authentication is who you are. Authorization is what you are allowed to do. They are related, they are often built by the same team, but they are distinct systems — and confusing them causes real security bugs.

This guide draws a clear line between the two and explains how they work together in a real application.

Authentication: Proving Identity

Authentication is the process of verifying that a user is who they claim to be. It answers the question: "Who is this?"

When a user logs in with an email and password, the system checks that the password matches the stored hash. When they authenticate with Google via OAuth, the system receives a verified identity from Google. When they use a passkey, the device signs a challenge with a private key only it holds.

In each case, the outcome is the same: the system has confirmed an identity. From this point forward, the system knows who is making requests.

Common authentication mechanisms:

• Password-based login with hashed storage
• One-time passwords (OTP) via email or authenticator app
• Passkeys and WebAuthn
• Social login via OAuth and OpenID Connect
• SAML for enterprise single sign-on

Authentication is typically handled at the entry point of an application — the login flow — and the result is stored in a session or token for the duration of the user's session.

Authorization: Determining Access

Authorization is what happens after authentication. It answers the question: "What is this user allowed to do?"

A confirmed identity does not automatically grant access to everything in the system. An authenticated employee should be able to read their own HR records but not their colleague's. An authenticated user on a SaaS platform should be able to manage their own organization but not modify another organization's data.

Authorization checks happen throughout the application — before sensitive reads, before writes, before any operation that should be restricted.

Common authorization models:

• RBAC (Role-Based Access Control): permissions are attached to roles; users are assigned roles.
• ABAC (Attribute-Based Access Control): permissions are determined by evaluating attributes of the user, the resource, and the environment.
• ACL (Access Control Lists): each resource has a list of users or groups that can access it.
• Ownership-based: a user can access resources they own (their own posts, their own documents).

Why the Distinction Matters in Practice

Conflating authentication and authorization leads to specific categories of bugs.

Checking authentication instead of authorization. A route that verifies if (user) — i.e., "is anyone logged in?" — without checking what that user is allowed to do grants all authenticated users access to everything behind that check. This is authentication without authorization.

Relying on authentication to imply authorization. An internal admin dashboard that assumes all authenticated users are admins — because "only admins know the URL" — is missing an authorization layer entirely.

Broken object-level authorization. A user who is authorized to edit their own posts can also edit another user's posts by changing the post ID in the request, because the authorization check only verified that the user can edit posts in general, not that they own this specific post.

These are not theoretical — they are among the most commonly exploited vulnerability categories in production web applications.

How They Work Together

In a typical web application, authentication and authorization work in sequence on every protected request:

1. Authentication middleware runs first. It reads the session cookie or Authorization header, verifies the token or session ID, and attaches a verified user identity to the request context.
2. Authorization middleware or logic runs second. It checks whether the verified user has permission to perform the requested action on the requested resource.

If either check fails, the request is rejected — with a 401 Unauthorized response if authentication fails (no valid identity), or a 403 Forbidden response if authentication passes but authorization fails (identity confirmed, but access denied).

The HTTP status codes encode the distinction:

• 401: the server does not know who you are. Authenticate and try again.
• 403: the server knows who you are. You do not have access.

A Concrete Example

A project management application has the following behavior:

• Authentication: any registered user can log in.
• Authorization: users can view projects they are members of; project admins can invite members; organization owners can delete projects.

The logic for viewing a project looks like this in sequence:

1. Verify the user is logged in (authentication).
2. Verify the user is a member of the project they are trying to view (authorization — object-level).
3. If they are a project admin, enable admin actions in the UI (authorization — role-level).

Each of those steps is necessary. Skipping any of them creates a gap.

Common Beginner Mistakes

• Protecting only the UI, not the API. Hiding an admin button in the interface does not prevent a user from calling the underlying API endpoint directly. Authorization must be enforced on the server.
• Over-relying on "security through obscurity." An endpoint that is not linked in the UI is not protected. Endpoints must be explicitly protected with authorization checks.
• Treating role checks as binary. "Is this user an admin?" is often not a sufficient authorization check. "Is this user an admin for this specific resource in this specific tenant?" is the right question for most multi-tenant applications.

Authentication and authorization are not the same problem, and they are not solved by the same code. Getting them both right — and keeping them cleanly separated — is the foundation of a trustworthy application.

If you are building or reviewing an application's auth system and want expert guidance on both layers, Clixo works with product teams on production-grade authentication and authorization.