Welcome back to Cybersecurity from Zero to Hero, the series where I learn security from scratch and write it down while the confusion is still fresh. In post two we untangled threats, vulnerabilities and risk. Today we tackle two words that even experienced developers mix up in conversation: authentication and authorization.
They sound alike, they often happen within the same second, and they get abbreviated to the nearly identical authn and authz. But they answer two completely different questions, and confusing them has caused real breaches.
🎟️ The nightclub analogy
Picture a nightclub with a bouncer and a VIP area.
Authentication asks: who are you, and can you prove it? That is the bouncer at the front door checking your ID against your face. You claim an identity, then you prove it. If the proof fails, you never get inside at all.
Authorization asks: what are you allowed to do now that you are inside? Your regular ticket gets you the main floor. It does not get you into the VIP area, and it definitely does not get you behind the bar pouring drinks. The second bouncer at the VIP rope is not asking who you are again. He is asking what your ticket permits.
One sentence to remember forever: authentication is about identity, authorization is about permission. You cannot have the second without the first, but proving who you are never automatically entitles you to everything.
💻 Translating it to computers
Authentication is the login. Username plus password, a fingerprint, a code from your authenticator app. The system verifies you are who you claim to be. We will spend two full posts on this soon, because passwords and multi-factor authentication each deserve their own deep dive.
Authorization is everything after the login. Can this account read that file? Can it delete other users? Can it see the admin dashboard? In real systems this runs through things like roles and permissions. A regular user and an admin might log in through the same screen, and the difference between them is pure authorization.
Here is why the distinction matters for security. Some of the ugliest vulnerabilities are authorization failures, not authentication failures. The attacker logs in as a completely legitimate low level user, then reaches data or actions that should have been off limits. Nothing about the login was broken. The system simply forgot to check the ticket at the VIP rope. In the web security world this shows up as broken access control, and it currently sits at the very top of the OWASP Top 10 list of web application risks. We will meet it hands on in phase four of this series.
A tiny example of the difference in code terms. Changing a URL from /account/1234 to /account/1235 and seeing someone else's data is an authorization failure. Guessing someone's password is an authentication failure. Same damage, totally different broken door.
📝 What I actually did: mapping a real login flow
The hands on exercise this time needs nothing but a browser. I picked a site I use daily and wrote down every identity and permission step from arrival to action. Try it with any site you like. Mine looked like this:
Step 1, the claim. I typed my email. That is me claiming an identity. No proof yet.
Step 2, the proof. I typed my password. First authentication factor: something I know.
Step 3, more proof. The site asked for a six digit code from my phone. Second factor: something I have. Two proofs, one identity. This is multi-factor authentication, coming up in post 5.
Step 4, the session. After login the site set a cookie in my browser. I found it in DevTools under Application, then Cookies. That cookie is my wristband. For the rest of the visit the site checks the wristband, not my ID. This also explains something I never understood before: logging out just destroys the wristband. My password did not change. The session ended.
Step 5, the permissions. I opened my account settings and saw sections I can use, and I remembered that an admin of the same site sees panels I do not. Same login flow, different tickets. That gap between what I see and what an admin sees is authorization, drawn as a user interface.
Five steps, and the first three were authentication while the last two were session and authorization. Once you map one site this way, you start seeing the pattern absolutely everywhere.
🤔 What confused me today
Is the session cookie authentication or authorization? It puzzled me because it feels like both. The cleanest answer I found: the cookie is proof of an already completed authentication, a temporary stand in for your ID so you do not retype your password on every click. The system still runs authorization checks against your permissions on every request. The wristband proves you were checked at the door. It does not decide what you may touch.
Why do sites make me re-enter my password before sensitive actions like changing email? Now I can name it: that is reauthentication. The site trusts the wristband for browsing, but for dangerous actions it wants fresh proof of identity, in case someone walked up to my unlocked laptop. Annoying, and correct. It is the same tension we met in post one between availability and confidentiality.
⏭️ Next in this series
Post 4 covers passwords and hashing, including why a well built site literally cannot tell you your own password, and why that is exactly how it should be. The hands on part builds a tiny hashing demo in Python. Follow the series so you do not miss it.
Top comments (1)
The distinction becomes clearest when you look at logs. Authentication says who showed up; authorization says what that identity was allowed to do at that exact moment. Most serious bugs I see are not “unknown user got in,” but “known user reached the wrong capability.”