Authentication vs Authorization

People mix these two up all the time, and honestly it’s easy to see why. They sound similar, they both start with “auth”, and they both show up the moment you try to use any app. So let’s clear it up.

• Authentication is about proving who you are. Like showing your ID.
• Authorization is about deciding what you’re allowed to do. Like which doors your keycard opens.

Here’s the simplest way to keep them apart:

• Authentication asks: “Are you really Alex?”
• Authorization asks: “Okay Alex, are you allowed to do this?”

One checks your identity, the other checks your permissions. They happen one after the other, and they are not the same thing. By the end of this lesson you’ll never confuse them again, even under interview pressure.

🎯 Why This Matters

This isn’t just a definitions question. It shows up in real systems and real interviews:

• It’s a classic security interview question, and getting the words wrong is an instant red flag. If you say “authentication” when you mean “authorization”, the interviewer notices right away.
• Almost every app you’ll ever build needs both. Users have to log in, and then the app has to decide what each user can touch.
• Most real security bugs live in the gap between these two. An app might check who you are but forget to check whether you’re allowed, and that’s how people end up seeing data that isn’t theirs.

So this is a small idea with big consequences. We’ll keep it beginner-correct, plain, and easy to remember.

🪪 Real-World Analogy

Think about going to the airport. Two very different checks happen there, and they map perfectly onto our topic:

• First, at security, someone looks at your ID and your face. They’re confirming you are really the person on the ticket. That check is authentication.
• Later, at the gate, the staff scan your boarding pass. They’re checking whether you’re allowed onto this specific flight, in this specific seat. That check is authorization.

See the difference? Your ID proves who you are. Your boarding pass decides where you’re allowed to go.

An office works the same way:

• Your ID badge proves you’re an employee. That’s authentication, the building knows it’s really you.
• But your badge only opens certain doors. The server room might stay locked for you while it opens for the IT team. That’s authorization, deciding which rooms you can enter.

Same badge, two jobs. Hold this picture in your head, because every example below comes back to it.

🔐 What is Authentication

Authentication is the step where the system makes sure you are who you claim to be. It’s proving your identity, nothing more.

• The word itself is sometimes shortened to authn in security writing, so don’t get thrown off when you see it.
• It always comes first. Before an app can decide what you’re allowed to do, it has to know who you actually are.
• A real-world example is logging into Gmail. You type your email and password, and Gmail checks that they match. That whole “is this really you” check is authentication.

So how does a system actually verify you? It usually asks for one or more proofs:

• Something you know. A password or a PIN. You prove it’s you because only you should know the secret.
• Something you have. A one-time code, often called an OTP, sent to your phone or generated by an app. (OTP is short for One-Time Password.) You prove it’s you because only you have the phone.
• Something you are. Your fingerprint or your face. This is called biometrics, and you prove it’s you with a part of your body.

When an app asks for two of these together, like a password plus an OTP, that’s called multi-factor authentication, or MFA. The idea is simple: even if someone steals your password, they still don’t have your phone, so they still can’t get in.

🛂 What is Authorization

Authorization is the step that decides what you’re allowed to do once the system already knows who you are. It’s about permissions, not identity.

• It’s sometimes shortened to authz, the partner abbreviation to authn.
• It always comes after authentication. The system first confirms you’re Alex, and only then checks what Alex is permitted to do.
• A real-world example is a shared Google Doc. You’re logged in, so Gmail knows it’s you. But whether you can edit the doc, or only view it, or delete it, that’s authorization deciding for you.

How do systems usually handle this? The common approach is to group permissions:

• Roles. Instead of setting rules for each person one by one, the system gives you a role like “admin”, “editor”, or “viewer”. This idea is called role-based access control, or RBAC, and it just means your role decides what you can do.
• Permissions. A role is really a bundle of permissions, the individual yes-or-no rules like “can delete posts” or “can read billing”. An admin role bundles many permissions, a viewer role bundles very few.

So in a blog app, an admin can publish and delete any post, an editor can edit posts, and a viewer can only read. Same login screen for everyone, but very different powers once they’re in. That difference is authorization at work.

⚖️ Authentication vs Authorization

Here’s the side-by-side. If you remember one thing from this lesson, make it this table.

A quick memory trick: autheNtication is about who you are, authorizaTion is about what you can do. Identity first, then permission.

🔄 How They Work Together

These two aren’t rivals, they’re a team. They run in a fixed order, and the order really matters:

• First the user logs in, and the system runs authentication to confirm their identity.
• Only if that passes does the system move on to authorization and check their permissions.
• Then, based on those permissions, the action is either allowed or denied.

Here’s that flow as a diagram.

Now, why does the order matter so much? Because one without the other is broken:

• Authentication without authorization means you let people in but never check what they can do. So a regular user might end up deleting everyone’s data. The front door is locked, but every inside door is wide open.
• Authorization without authentication is even worse. You’d be checking permissions for someone whose identity you never verified. It’s like handing out boarding passes without ever looking at an ID. You can’t safely decide what someone may do if you don’t even know who they are.

So the safe pattern is always the same: authenticate first, authorize second. Identity, then permission, every single time.

🧩 Real Examples

Let’s make this concrete with a few app scenarios you’d actually meet:

• Gmail. Typing your password is authentication, Gmail confirming it’s really you. Then whether you can open a teammate’s mailbox is authorization, and the answer is usually no.
• A shared Google Doc. You log in, so you’re authenticated. But the doc owner gave you “view only”, so when you try to edit, authorization steps in and blocks you.
• Netflix. Signing in with your account is authentication. Whether you can watch is authorization, and if your plan expired, you’re authenticated but not authorized to stream.
• A company dashboard. Every employee logs in the same way, that’s authentication. But only managers can see salary reports, that’s authorization based on their role.

Notice the pattern in all of them. Getting in is one question. What you can do once you’re in is a completely separate question.

⚠️ Common Mistakes and Misconceptions

A few ideas trip people up constantly. Let’s clear them out:

• “Authentication and authorization are the same thing.” They’re not. One proves identity, the other grants permission. Using the words interchangeably is the fastest way to look unprepared in an interview.
• “Once you log in, you can do anything.” Logging in only proves who you are. What you can do still depends on your roles and permissions, which is a separate check.
• “You can authorize someone without authenticating them first.” You can’t, safely. Deciding what someone may do is meaningless if you haven’t confirmed who they are. Identity has to come first.
• “A strong password covers everything.” A strong password helps with authentication, but it does nothing for authorization. A perfectly logged-in user can still be blocked from actions they shouldn’t perform, and that’s by design.

🛠️ Design Challenge

Try this one on your own to test yourself.

Imagine you’re building a simple blogging app with three kinds of users: admins, writers, and readers. Sketch out how authentication and authorization would work:

• How would each user prove who they are when they log in? That’s your authentication step.
• Once they’re in, what should each role be allowed to do? For example, maybe admins can delete any post, writers can create and edit their own posts, and readers can only read.
• Where would you check permissions, just at login or on every action like “delete this post”?

Write down the roles, the permissions each one gets, and the order of the checks. This is exactly the kind of access-control thinking interviewers love to see.

🧩 What You’ve Learned

You can now tell these two apart with confidence. Here’s what you’ve picked up.

• ✅ Authentication proves who you are, using passwords, OTP, MFA, or biometrics.
• ✅ Authorization decides what you’re allowed to do, using roles and permissions like RBAC.
• ✅ Authentication always happens first, then authorization.
• ✅ Authentication asks “who are you?”, authorization asks “what can you do?”.
• ✅ One without the other is broken, and permissions should be checked on every protected action.

🧠

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

1. 1

   Which question does authentication answer?

   What are you allowed to do? Who are you? How many requests have you sent? Where is your data stored?
   Check

   Why: Authentication proves identity, answering 'who are you?', while authorization answers 'what can you do?'.

2. 2

   In the right order, which check happens first?

   Authorization, then authentication Authentication, then authorization They happen at the same time Only one is ever needed
   Check

   Why: You confirm identity first, then decide permissions, because you can't sensibly grant access to someone you haven't identified.

3. 3

   Combining a password with a one-time code sent to your phone is an example of what?

   Role-based access control Multi-factor authentication Authorization Least privilege
   Check

   Why: Using two different proofs together, like something you know plus something you have, is multi-factor authentication.

4. 4

   Why should authorization be checked on every protected action, not just at login?

   Because login is too slow to repeat Because a logged-in user can still try actions they shouldn't, like opening another user's invoice Because passwords change on every request Because roles are only created after login
   Check

   Why: A valid login does not mean every action is allowed, so each protected action needs its own permission check.

Score: 0 / 4 Reset

🚀 What’s Next?

You’ve got the core security idea down. Next, let’s look at how apps actually remember that you’re logged in and keep things fast and safe.

• Sessions vs JWT shows how apps keep you authenticated after login without asking for your password on every click.
• Rate Limiting Explained covers how systems stop abuse by capping how often someone can hit your endpoints.

Get these two next, and you’ll have a solid grip on the security basics every backend and system design interview leans on.