Authentication vs Authorization

Hecer Mehdiyeva — Mon, 06 Apr 2026 14:26:25 +0000

You've probably seen these two words a hundred times. You might even use them interchangeably. Don't worry — almost everyone does at first. Let's fix that, once and for all.

Picture a nightclub

It's Friday night. There's a line outside a club. Two things happen before you get in:

The bouncer checks your ID — "Are you who you say you are? Are you old enough?"
Once inside, staff check your wristband — "VIP? You get the private lounge. Regular ticket? Bar and dance floor only." That's it. That's the whole concept. Authentication = the bouncer checking your ID. Authorization = the wristband deciding where you can go.

Now let's get a little more technical

In software, every time a user logs into an app, these two processes are quietly running behind the scenes.

Authentication — "Who are you?"

When you type your email and password into an app, the system checks: does this password match what we have stored for this email? If yes — you're authenticated. You've proven your identity.
Common authentication methods:

Password + username (classic)
OAuth ("Sign in with Google")
Biometrics — fingerprint, Face ID
One-time passwords (OTP) sent by SMS or email
Magic links ### Authorization — "What can you do?"

Once you're logged in, authorization determines which parts of the app you can access. An admin can delete users. A regular user cannot. A free-tier customer can't use premium features. A moderator can remove posts but can't change billing settings.

Common authorization models:

Role-Based Access Control (RBAC) — "You're an admin, so you can do X"
Permission-Based — granular flags like can_edit, can_delete
Attribute-Based (ABAC) — rules based on user attributes, time, location
Ownership checks — "You can only edit your own posts"

The HTTP error codes give it away

Here's a neat trick to remember which is which — look at the HTTP status codes:

401 Unauthorized — Despite the confusing name, this means authentication failed. "I don't know who you are. Please log in."

403 Forbidden — This means authorization failed. "I know exactly who you are, but you're not allowed here."

Think of it this way: 401 is the bouncer turning you away at the door. 403 is the bouncer saying "I recognize you, but you're not on the VIP list."

Why does the order matter?

Authentication always comes first. You can't check what someone is allowed to do until you know who they are. It's a strict sequence:

Identify → Verify → Authorize

A common junior developer mistake is skipping authentication checks and jumping straight to authorization — or worse, trusting client-side data (like a user_role sent from the frontend) without verifying the user's identity server-side first.

Don't do that. Always verify the identity on the server before trusting any claims about what a user can do.

Quick cheat sheet

	Authentication	Authorization
Question	Who are you?	What can you do?
Purpose	Prove identity	Grant access
Examples	Login, OAuth, biometrics	Roles, permissions
HTTP error	401 Unauthorized	403 Forbidden
Order	First	Second

Wrapping up

These two concepts are foundational to almost every app you'll ever build. Get them confused and you'll end up writing security bugs that are embarrassing at best and catastrophic at worst. But now that you have the nightclub analogy in your head, you'll never mix them up again.
Authentication is the bouncer. Authorization is the wristband. Both are necessary. Neither is optional.
Happy coding. 🚀

This Code Will Betray You:

Hecer Mehdiyeva — Tue, 31 Mar 2026 19:03:29 +0000

🔐 This Code Will Betray You: The Hidden Flaw in Your Admin Panel
The Hidden Flaw in Your Admin Panel Imagine you've built a web application. Login system works, passwords are hashed, everything looks solid. You feel confident. Then someone simply types this URL:GET /admin/dashboard and walks right in. No attack tools, no exploit. Just a URL .This is Broken Access Control — ranked #1 on OWASP's list of the most critical web security risks. And it almost always comes from the simplest mistake.
Where Is the Flaw?
Take a look at this Flask code:_

__@app.route("/admin/dashboard")
def admin_dashboard():
    user_ id = session .get("user _id")

    if not user _id:
        return  jsonify ({"error": "Please log in"}), 401

    user = users. get(user_ id)
    return jsonify({"data": f" Welcome, {user['name']}! This is the admin panel."})

The code asks only one question: "Is this person logged in?"
What it never asks: "Does this person actually have permission to be here?"
So a regular user logs in, navigates to the URL, and gets this:

{"data": "Welcome, Ali! This is the admin panel."}

Ali is a regular user — but he's inside the admin panel. The code works perfectly. That's exactly why this bug goes unnoticed for so long.
**
The Fix**

def admin_ required(f):
    @wraps(f)
    def decorated(*args,  ** kwargs):
        user_ id = session .get("user _id")

        if not user_ id:
            return jsonify({"error": "Please log in"}), 401

        user = users. get(user_ id)

        if not user or user["role"] != "admin":
            return jsonify({"error": "Access denied"}), 403

        return f(*args, **kwargs)
    return decorated

@app.route("/admin/dashboard")
@admin_required
def admin_ dashboard():

@admin_ required — one line, full protection.

Write it once, attach it to every protected route. If you forget — it returns 403, not your admin data.

The Lesson

Authentication and authorization are not the same thing.

Authentication asks: "Who are you?"
Authorization asks: "What are you allowed to do?"

Locking the front door while leaving every room inside wide open is only half a security model.

And hiding the URL doesn't help either. /admin/secret-panel-xyz is not protection — it's just obscurity. Anyone who finds it gets in.

Every time you write an endpoint, ask yourself:

"Am I checking that the user is logged in — or that they're allowed to be here?"

One small line of code. One very large difference.

This article is part of a series on Broken Access Control. Next up: IDOR — how attackers access anyone's data using nothing but an ID.

🏷️ Dev.to Tags

#python #security #webdev #flask #beginners

DEV Community: Hecer Mehdiyeva