The Difference Between Authentication and Authorization (With Real Examples)

Authentication is proving who you are. Authorization is proving what you can do. Here's the difference — with real examples you'll actually remember.

8 min read
...
Software
The Difference Between Authentication and Authorization (With Real Examples)

Most people mix these up. Including people who should know better.

I've sat through countless security meetings where someone says "we need to authorize the user" when they mean "we need to log them in."

The words sound similar. They both start with "auth." They both relate to security.

But they are not the same thing. Not even close. I have failed this in an interview many years back... That's why I'm sharing this to you.

Mixing them up gets you hacked. Let me explain why.


Authentication: Who are you?

Authentication answers one question: Are you who you say you are?

That's it. Nothing more.

When you type your password into a website, that's authentication. When you scan your fingerprint to unlock your phone, that's authentication. When you tap your badge to enter the office, that's authentication.

Authentication proves identity.

Real examples:

  • You show your driver's license at the airport. That's authentication. The TSA agent verifies the photo matches your face.
  • You enter your email and password into Gmail. That's authentication. Google checks that the password matches the email.
  • You use Face ID to open your banking app. That's authentication. Your phone verifies it's actually you.

After authentication, the system knows who you are. But it doesn't know what you're allowed to do yet.

That's a separate step.


Authorization: What can you do?

Authorization answers a different question: Are you allowed to do this specific thing?

After the system knows who you are, it needs to check your permissions.

You might be authenticated as an employee. But are you authorized to view payroll data? Probably not unless you're in HR.

You might be authenticated as a customer. But are you authorized to delete your account? Yes. Are you authorized to refund someone else's order? No.

Authorization checks permissions.

Real examples:

  • You log into your work email (authentication). Then you try to open the CEO's calendar. The system checks: is your role authorized to view executive calendars? Probably not. That's authorization.
  • You log into Netflix (authentication). Then you try to watch an R-rated movie. Netflix checks: is your profile authorized for mature content? If you're on a kids profile, no. That's authorization.
  • You log into your bank account (authentication). Then you try to transfer $10,000. The bank checks: is your account authorized for transfers above $5,000? If not, the transfer is blocked. That's authorization.

Notice the pattern: authentication happens first. Then authorization checks happen on every action.


The Simple Way to Remember

Authentication = proving identity (who you are)

Authorization = checking permissions (what you can do)

Here's a mnemonic I use:

  • AuthN (authentication) has an "N" for name (who you are)
  • AuthZ (authorization) has a "Z" for zone (what you can access)

Another one:

  • Authentication = passport (proves you're you)
  • Authorization = visa (proves what you're allowed to do in the country)

You can have a passport (authentication) but still need a visa to enter certain countries (authorization).


Real-World Scenario: Airport Security

Let me walk through a complete example.

Step 1: Authentication

You walk up to the TSA agent. You hand over your ID and boarding pass. The agent looks at your face, looks at the photo, and says "yep, that's you."

Now you're authenticated. The agent knows who you are.

Step 2: Authorization

You walk to your gate. You try to board the plane. The gate agent scans your boarding pass.

The system checks: is this passenger authorized to board this specific flight? Yes, you have a ticket.

But what if you tried to board a different flight? The system would check: is this passenger authorized to board this flight? No. You don't have a ticket for that one.

What if you tried to enter the first class cabin with a coach ticket? The flight attendant checks: is this passenger authorized to sit here? No.

Authentication got you through the door. Authorization determines exactly where you can go and what you can do.


Real-World Scenario: Your Company's Systems

Another example.

You join a new company. HR sets up your account.

Authentication: You set a password. You enable two-factor authentication. Now the system can verify it's really you when you log in.

Authorization: HR assigns you a role. Maybe "Junior Developer" or "Sales Rep" or "Manager."

Based on that role, the system grants permissions:

  • Junior Developer: can view code, submit pull requests, cannot deploy to production
  • Sales Rep: can view customer data, create quotes, cannot access source code
  • Manager: can view team calendars, approve time off, cannot change server configurations

You authenticate once per day (log in). Your authorization is checked on every single action (can you view this file? can you approve this expense? can you deploy this code?).


Why the Difference Matters

Here's where people get into trouble.

Mistake #1: Assuming authentication is enough

"I logged in, so I should be able to see everything."

No. Logging in proves who you are. It doesn't grant unlimited access. You still need authorization checks.

Many data breaches happen because a system authenticated a user but never checked if they were authorized to view that specific data.

Mistake #2: Mixing up the order

You cannot authorize someone before authenticating them. That makes no sense. "You're allowed to do this thing, random stranger."

Authentication first. Then authorization.

Mistake #3: Using the same word for both

"I authed the user" means nothing. Say "I authenticated the user" or "I authorized the action." Be specific.


How Authentication Works (Briefly)

I won't go deep, but here's the basic flow:

  1. User provides credentials (password, fingerprint, security key)
  2. System verifies those credentials against a stored value
  3. System issues a token (session cookie, JWT, etc.)
  4. User presents that token on subsequent requests

Common authentication methods:

  • Password (weakest, but common)
  • Multi-factor authentication (password + code from phone)
  • Biometric (fingerprint, face scan)
  • Security keys (physical USB/NFC device)
  • SSO / OAuth ("Log in with Google")

Authentication is about the first interaction. Proving identity.


How Authorization Works (Briefly)

Authorization happens on every request after authentication.

Common authorization models:

  • Role-based (RBAC): User has a role. Role has permissions. Example: "Admin" role can delete users. "Viewer" role cannot.
  • Attribute-based (ABAC): Decisions based on attributes (user's department, time of day, resource type). Example: "Managers can view salaries of employees in their own department only."
  • Access control lists (ACL): Each resource has a list of who can access it. Example: "This document is readable by User A, User B, and User C."

Authorization is about every interaction. Checking permissions.


The Most Common Bug I See

Junior developers often forget authorization checks.

They authenticate the user, then assume that user can do anything.

Here's the bug:

# BAD: Authentication only, no authorization
def delete_order(order_id, current_user):
    # User is authenticated (we know who they are)
    order = Order.find(order_id)
    order.delete()
    return "Order deleted"

This function lets any logged-in user delete any order. Even orders that belong to other customers.

The fix:

# GOOD: Authentication + Authorization
def delete_order(order_id, current_user):
    order = Order.find(order_id)
    
    # Authorization check
    if order.user_id != current_user.id:
        return "You are not authorized to delete this order"
    
    order.delete()
    return "Order deleted"

Authentication told us who current_user is. Authorization checked that they own this specific order.

Always check both.


The Bottom Line

Authentication Authorization
Question Who are you? What can you do?
When Once per session (usually) Every action
Example Password, fingerprint, badge Permissions, roles, ACLs
Failsafe Without authentication, nothing else matters Without authorization, authenticated users can do anything

Authentication without authorization is useless. You know who someone is, but you let them do everything.

Authorization without authentication is impossible. You can't check permissions for someone you haven't identified.

You need both. In the right order.


One Last Example

You walk into a library.

Authentication: You show your library card. The librarian verifies it's really your card.

Authorization: The system checks: are you allowed to borrow DVDs? Yes, you have a standard membership. Are you allowed to borrow rare books from the special collection? No, that requires researcher status.

You're authenticated as "cardholder #4829." You're authorized for some things, not others.

Same person. Different permissions for different actions.

That's the difference.


Written by Fredsazy — because knowing the difference keeps your data safe.


Iria Fredrick Victor

Iria Fredrick Victor

Iria Fredrick Victor(aka Fredsazy) is a software developer, DevOps engineer, and entrepreneur. He writes about technology and business—drawing from his experience building systems, managing infrastructure, and shipping products. His work is guided by one question: "What actually works?" Instead of recycling news, Fredsazy tests tools, analyzes research, runs experiments, and shares the results—including the failures. His readers get actionable frameworks backed by real engineering experience, not theory.

Share this article:

Related posts

More from Software

View all →