Marcos W. Ferreira

When building modern web applications, security is often the most intimidating aspect. Two terms that are frequently confused—even by experienced developers—are Authentication and Authorization. While they sound similar and are closely related, they solve completely different problems.

In this article, we will demystify these concepts, explore modern protocols like OAuth 2.0 and OpenID Connect, and discuss best practices for securing your architecture.

1. The Core Difference: AuthN vs. AuthZ

The easiest way to remember the difference is through a simple analogy:

Authentication (AuthN) is about Identity: It asks the question, "Who are you?" It's the process of verifying that a user or system is who they claim to be. Think of it as showing your passport at the airport.
Authorization (AuthZ) is about Permissions: It asks the question, "What are you allowed to do?" Once the system knows who you are, it must determine if you have access to a specific resource. Think of it as your boarding pass dictating which gate and plane you can enter.

If you let a user into the dashboard without checking their credentials, that's an AuthN failure. If you let a standard user delete the database because they guessed the admin endpoint URL, that's an AuthZ failure.

2. Authentication (AuthN) Strategies

Historically, authentication was simple: a user sends a username and password, the server validates it against a database, and gives the user a session cookie. Today, architectures are distributed, requiring different approaches.

Sessions vs. Tokens

Stateful Sessions: The server stores a session ID in its memory (or a fast database like Redis) and sends a cookie to the browser. The browser sends the cookie on every request. Pros: Easy to invalidate (logout), very secure. Cons: Harder to scale horizontally across multiple microservices.
Stateless Tokens (JWT): The server issues a signed token containing the user's identity. The client stores it and sends it via the Authorization header. The server verifies the signature without looking up a database. Pros: Highly scalable, great for microservices. Cons: Extremely difficult to invalidate before expiration.

Multi-Factor Authentication (MFA)

Passwords alone are no longer enough. MFA requires users to provide two or more verification factors:

Algo que você sabe (senha).
Algo que você tem (um aplicativo autenticador no smartphone ou chave de hardware como YubiKey).
Algo que você é (biometria). Wait, I wrote this in Portuguese... Let me fix it.
Something you know (password).
Something you have (a smartphone authenticator app or hardware key like YubiKey).
Something you are (biometrics).

3. Authorization (AuthZ) Models

Once authenticated, how do you manage what the user can do?

Role-Based Access Control (RBAC)

The most common model. Users are assigned roles (e.g., Admin, Editor, Viewer), and permissions are tied to those roles.

Example: Only users with the Admin role can access the /api/users endpoint.
Limitations: Can become complex ("role explosion") when you need granular permissions, like "User can only edit documents they created."

Attribute-Based Access Control (ABAC)

A more granular model where access rights are granted through policies that evaluate attributes (user attributes, resource attributes, and environmental conditions).

Example: "Allow access if user.department == resource.department AND time < 18:00."

4. Decoding the Protocols: OAuth 2.0 and OIDC

If you've ever used "Log in with Google", you've used these protocols.

OAuth 2.0

OAuth 2.0 is an Authorization framework. It was designed to allow a third-party application to access a user's resources without exposing their password.

Scenario: A printing app wants to access your Google Photos. Instead of giving the printing app your Google password, Google gives the app an Access Token that only has permission to read photos, and nothing else.
Misconception: OAuth 2.0 was not designed for authentication, though it was heavily abused for it in the past.

OpenID Connect (OIDC)

OIDC is an Authentication layer built on top of OAuth 2.0. Since OAuth 2.0 didn't provide a standard way to communicate who the user actually is, OIDC was created. It introduces the ID Token (a JWT), which contains claims about the authenticated user's identity (like their name and email).

5. The JWT Dilemma

JSON Web Tokens (JWT) are ubiquitous, but they are often misused.

When to use JWTs:

Server-to-server communication (e.g., passing context between microservices).
As short-lived Access Tokens in an OAuth 2.0 flow.

When NOT to use JWTs:

As a replacement for standard user sessions in a monolithic web application. If you issue a JWT valid for 30 days and the user gets hacked, you cannot revoke that token easily because the server doesn't keep state. You would have to implement a token blacklist, which defeats the purpose of being stateless.

6. Golden Rules of Security

Regardless of the stack you choose, follow these best practices:

HTTPS Everywhere: Never transmit tokens or passwords over unencrypted HTTP.
Never Store Plaintext Passwords: Always hash passwords using strong algorithms like bcrypt, Argon2, or PBKDF2 with unique salts.
Secure Your Cookies: If using cookies, always set the HttpOnly (prevents XSS attacks from reading the cookie), Secure (ensures transmission only over HTTPS), and SameSite (mitigates CSRF attacks) flags.
Keep Tokens Short-Lived: Access tokens should expire quickly (e.g., 15 minutes). Use Refresh Tokens to obtain new access tokens without requiring the user to log in again.
Implement Rate Limiting: Protect your authentication endpoints from brute-force and credential stuffing attacks.

Security is not a feature you bolt on at the end of development; it's an architectural foundation. Understanding the distinction between AuthN and AuthZ is the first step toward building resilient and trustworthy applications.