Authenticated ≠ Authorized: When Things Go Wrong

In the world of digital security, two terms get thrown around constantly: Authentication (AuthN) and Authorization (AuthZ). They are often used interchangeably, but they represent fundamentally different concepts.

Mixing them up isn’t just a pedantic terminology error. It’s the root cause of some of the biggest data breaches in history, including the exposure of 885 million file records from First American Financial Corp.

The Core Difference: Identity vs. Permissions

1. Authentication (AuthN)

Authentication is the process of verifying identity. It acts as the digital bouncer, answering the question: Is this person truly who they claim to be?

Robust authentication typically relies on one or more of the “Three Factors of Authentication” defined by NIST SP 800-63B:

1. Something You Know (Knowledge): Passwords, PINs, or answers to security questions. (Weakest)
2. Something You Have (Possession): A physical device like a YubiKey, a smartphone receiving an SMS/OTP, or an RSA token.
3. Something You Are (Inherence): Biometrics like Fingerprints, FaceID, or retinal scans.

Emerging Factor: “Something You Do” (Behavioral Biometrics) analyzes patterns like typing speed, mouse movements, or gait analysis to continuously authenticate users.

2. Authorization (AuthZ)

Authorization acts on the assumption that identity is already established. It answers the question: Does this authenticated user have permission to perform this specific action?

Authorization strategies vary by complexity:

• RBAC (Role-Based Access Control): Permissions are assigned to roles (e.g., “Manager”, “Employee”), and users are assigned to roles. Example: Only “Editors” can publish articles.
• ABAC (Attribute-Based Access Control): A fine-grained model evaluating attributes of the user, resource, and environment. Example: “Junior Traders” (User Attribute) can only “Trade” (Action) “Stocks” (Resource) during “9am-5pm” (Environment).
• ACLs (Access Control Lists): A list of permissions attached to a specific object. Example: User A has read/write access specifically to document.txt.

The Technical Reality: OAuth 2.0 vs. OpenID Connect

This is where many developers get confused. You will often hear sentences like “We use OAuth for login.” This is technically incorrect and dangerous.

OAuth 2.0 is for Authorization

OAuth 2.0 is a standard designed to grant delegated access to API resources. When you use OAuth, an application issues an Access Token.

This token tells an API: “This app is allowed to validly read Google Drive files on behalf of the user.” It does not tell the app who the user is. An Access Token is like a hotel key card it opens the door, but it doesn’t have your name printed on it.

OpenID Connect (OIDC) is for Authentication

OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol. It introduces a standardized specifically for identity: the ID Token.

The ID Token is a JSON Web Token (JWT) that contains structured claims about the user (name, email, unique subject ID).

A Note on JWTs (JSON Web Tokens)

You will often encounter JWTs when building authentication systems. They are widely used because they are stateless the server doesn’t need to keep a record of every logged-in user in a database session table. All the data (user ID, expiration, roles) is cryptographically signed inside the token itself.

Pros:

• Scalability: Great for microservices and serverless architectures as no central session DB is needed.
• Performance: One less database lookup per request.

Cons & Risks:

• Revocation is Hard: Since the server doesn’t track tokens, you can’t easily “log out” a user server-side or ban them immediately without complex workarounds (like denylists).
• Security: If a JWT is stolen, it’s game over until it expires.
• Storage: Storing JWTs in localStorage makes them vulnerable to XSS attacks.

Best Practice: Store your tokens in HttpOnly, Secure cookies. This prevents JavaScript from reading them, effectively neutralizing XSS theft vectors.

Authenticated ≠ Authorized: When Things Go Wrong

The most dangerous security failures happen when a system assumes that because someone is authenticated (logged in), they are authorized to do whatever they want.

The “Insecure Direct Object Reference” (IDOR)

IDOR is a classic authorization failure, currently part of the #1 vulnerability category in the OWASP Top 10.

The Scenario: You log into a medical portal. The URL looks like this: https://hospital.com/records?patient_id=1001

The Attack: You change the ID to 1002. https://hospital.com/records?patient_id=1002

The Failure: If the system shows you patient 1002’s records just because you are a validly logged-in user, that is an Authorization failure. The system checked who you were (Authentication: Passed), but failed to check if you had permission to see record 1002 (Authorization: Failed).

Real-World Breach: First American Financial Corp (2019)

This exact vulnerability led to the exposure of 885 million records.

1. Authentication: Users could log in efficiently.
2. Authorization Failure: The application used sequential document IDs in the URL. Anyone who had a link to one document could simply change the numbers to view other people’s bank account numbers, wire transaction receipts, and mortgage paperwork. No one checked if the viewer owned the document.

The “Confused Deputy” Problem

Another subtle authorization issue is the Confused Deputy problem. This occurs when a trusted service is tricked into performing an action by a malicious entity.

Classic Example: CSRF (Cross-Site Request Forgery)

1. You are logged into your banking website (Authenticated).
2. You visit malicious-site.com.
3. The malicious site has a hidden form that POSTs a transfer request to your-bank.com.
4. Your browser, acting as the “Deputy,” sees the request is for your-bank.com and helpfully attaches your session cookies (your authentication “Badge”).
5. The bank receives the request, sees the valid cookies (Authentication verified), and processes the money transfer.

The Fix: The bank needs to check intent, not just identity. This is why we use CSRF tokens or SameSite cookie policies - to ensure the authorization request originated from a trusted context.

Summary Checklist for Developers

To build secure systems, you must treat these as separate layers of your stack:

• Don’t Roll Your Own Identity: Use established providers like Auth0, AWS Cognito, or Clerk instead of hashing passwords yourself.
• Use OIDC for Login: Ensure you are receiving an ID Token to verify identity.
• Use OAuth 2.0 for APIs: Use Access Tokens with scoped permissions (e.g., read:files) to talk to your backend.
• Validate on the Backend: Never trust the frontend’s visibility state. Just because a “Delete” button is hidden in the UI doesn’t mean the API endpoint is secure.
• Check Every ID: If an API accepts a resource ID (like /users/123), always verify the current user actually owns or has access to ID 123.