The School Gate, the Cafeteria Pass, and Your Student ID: How AuthN, AuthZ, OAuth, and OIDC Work

You’ve probably done this a thousand times. You walk up to the school gate. You pull out your NFC student card. You tap it on the reader. A light turns green. The gate clicks open. You walk in.

It feels instant. But in that one second, the school just answered two questions:

1. Is this a valid card? (Did the school actually issue it?)
2. Does it belong to you? (Did the school give this specific card to this specific student?)

If both answers are yes, the gate opens. If either is no, the gate stays shut — and a teacher probably walks over to ask what’s going on.

That’s it. That’s the whole idea behind authentication — the school checking that you’re really you.

Most of the rest of this post is also about checking things. But the questions change, the answers change, and the metaphors change with them. By the end, you’ll know what AuthN, AuthZ, MFA, OAuth, and OIDC mean — even though the words sound like a robot sneezed.

Let’s start at the gate.

Authentication (AuthN): Who are you?

When you tap your NFC card at the gate, the school is doing one thing: confirming your identity. The technical name for this is authentication, often shortened to AuthN.

The system asks two questions:

• Is this card real? (The card has a serial number that’s registered in the school’s database.)
• Does this card belong to you? (Your photo, your name, and your student number are stored on the school’s server.)

If both answers are yes, the gate clicks open. If no, the gate stays shut.

AuthN answers one question: Who are you?

The whole process takes one second. But knowing who you are doesn’t tell the school what you’re allowed to do. That’s the next question.

Authorization (AuthZ): What are you allowed to do?

Once you’re inside, your NFC card still does work — but a different kind of work. Every door you walk past has a reader, and every reader asks the same question: “Is this student allowed in here?”

The technical name for this is authorization, often shortened to AuthZ.

Here’s how it works at the school:

• Library door — opens for any student. You tap, it clicks, you walk in.
• Teachers’ lounge — stays locked for students. Only staff cards open it.
• Gym — opens for any student, but not for visitors.

The card knows who you are (the AuthN from the gate) — but it also knows what kind of student you are. A grade-7 student can open the library. A teacher can open the teachers’ lounge. A visitor can open neither.

Here’s the part that trips most people up: you can be authenticated and still not authorized.

You’re a real student. Your card is real. The gate let you in (AuthN ✔). You walk up to the teachers’ lounge and tap. The door stays locked (AuthZ ✘). The system knows you’re Neo. It just doesn’t think you’re allowed in there.

That’s AuthN and AuthZ, working together. They’re not the same question — they’re not even close.

Multi-Factor Authentication (MFA): Who are you, really?

The library door doesn’t care much about who’s tapping — almost any student can open it. But some doors at the school are different. The server room, where the school keeps every student’s grades and records. That door doesn’t trust a single NFC tap.

To open the high-security door, you need two things, not one:

• Something you have — your NFC card (the same one from the gate).
• Something you know — a six-digit PIN that the school gave you at the start of the year.

You tap the card. The reader asks for the PIN. You type it in. The door opens.

The technical name for this is multi-factor authentication, often shortened to MFA. The “multi” means more than one factor. The “factor” means one of three kinds of proof.

There are three kinds of proof, called factor classes:

A single-factor check uses one of these. The gate uses one — your NFC card (something you have). The high-security door uses two — your card (have) plus your PIN (know).

At the gate, one factor (the card) is enough — the school just wants to know you’re a real student. At the high-security door, two factors are required — because what’s inside (your grades, your records) is worth more.

OAuth 2.0: Borrowing access safely

So far, everything has happened inside the school. But what if a system outside the school needs to act on your behalf?

Let’s say the school has a cafeteria app. You install it on your phone. You want to use it to buy lunch. The app needs to know who you are so it can charge your school account — but you don’t want to give the app your school password. (You use that password for everything; if the cafeteria app gets hacked, an attacker could log into your grades, your attendance, your email.)

This is exactly the problem OAuth 2.0 solves.

OAuth 2.0 is a protocol — a set of rules — for delegated authorization. The school doesn’t give the cafeteria app your password. Instead, the school gives the cafeteria app a temporary digital pass. We call that pass an access token.

Here’s how it works:

1. You tap your card at the cafeteria app (or click “log in with school”).
2. The school asks: “Do you want to give the cafeteria app a pass to buy food?”
3. You say yes.
4. The school issues a temporary digital pass — the access token — to the cafeteria app.
5. The pass says: “This student can buy food.”
6. The pass expires in an hour.

The cafeteria app uses the pass every time you buy lunch. It never sees your school password. If the app gets hacked, the attacker only gets the temporary pass — and the pass expires soon anyway.

There are three actors in this story:

• You, the student — the technical name is resource owner (you own your data and your permissions).
• The school — the technical name is authorization server (the system that issues the pass).
• The cafeteria app — the technical name is client (the system that receives the pass and uses it).

Here’s how the three actors connect:

The diagram reads from top to bottom. The student taps their card at the gate (top). The school issues two tokens to the cafeteria app: the access token (OAuth) and, in OIDC, an ID token (next section). The cafeteria app uses both tokens to buy lunch on the student’s behalf. The student never shares their password.

OpenID Connect (OIDC): Adding who you are to the pass

OAuth gives the cafeteria app a temporary pass — but the pass only says “this student can buy food.” It doesn’t say which student. That’s a problem: the cafeteria needs to know whose school account to charge.

OpenID Connect (OIDC) fixes this. OIDC is OAuth plus identity. When the school issues the temporary pass, it also issues a second token — the ID token — that contains the student’s verified identity:

• Student number
• Photo
• Full name
• Class / year

The ID token is signed by the school (so the cafeteria app can verify it’s real), and it tells the cafeteria app exactly who is buying lunch.

So now there are two separate tokens:

• Access token — the temporary digital pass (OAuth). Says what you can do.
• ID token — the verified identity (OIDC). Says who you are.

Both tokens are usually formatted as JWTs (JSON Web Tokens), which are just signed JSON objects. But they serve different purposes. The OpenID Connect Core 1.0 specification is the canonical reference if you want the deep dive — it covers the exact token format, the supported flows, and the cryptographic signing rules.

JWT scopes: Labels on the digital pass

By now you’ve heard the word token several times. A token is just a small piece of data the school hands out — a temporary digital pass that says who you are (or what you can do, or both).

The most common token format today is the JWT — JSON Web Token. A JWT is a string that looks like three long random words joined by dots: eyJhbGc...header.eyJzdWI...payload.SflKxw...signature. The first part is the header (what algorithm was used), the second is the payload (the actual data — your name, your permissions, and so on), and the third is the signature (a cryptographic stamp that proves the JWT wasn’t tampered with).

A JWT can carry lots of things, but one of the most important is a list of scopes. A scope is a label on the digital pass that says what the pass is allowed to do.

For our cafeteria example:

• "library access" — can borrow books.
• "cafeteria purchases" — can buy lunch.
• "gym entry" — can use the gym.
• "grades:read" — can read grades (uh oh).

The cafeteria app’s token only has "cafeteria purchases". It doesn’t have "grades:read". So when it tries to read grades, the school’s system says: “This pass isn’t labeled for that — denied.”

But what happens if the token arrives without any scope at all? It’s a valid pass — the signature checks out — but it has no labels. The receiving system cannot tell which doors the pass is meant to open.

There are two policies for that case:

• Default-deny (safer) — the system refuses access because the pass has no labels. “This pass has no scope, so we deny everything.”
• Default-allow (risky) — the system lets the pass do anything because it can’t tell what it’s not allowed to do.

The diagram shows the decision tree. If the JWT has no scope field, the safe choice is to deny (top-left branch). If it does have a scope field, the system reads the scopes and checks whether the requested action is in the granted set.

The five concepts in one paragraph each

If you’ve read this far, you already know the answer to “what’s the difference between AuthN and AuthZ?” You can also tell your friends why OAuth isn’t the same as logging in.

Here’s the recap:

• AuthN = tapping your NFC card at the school gate.
• AuthZ = which doors unlock when you tap.
• MFA = card + PIN at the high-security door.
• OAuth = a temporary digital pass for another system (like the cafeteria app) to act on your behalf.
• OIDC = a temporary digital pass with a verified student ID attached.
• No scope in a JWT = a pass with no labels — confusing for teachers and systems, potentially unsafe.

If you want to keep going from here, the rest of the post world has more depth. For the hands-on next step — “how do I keep my own passwords safe?” — see the Password Managers post. And if you liked this intro and want the deeper-management read on what happens when auth gets tangled at the organisational level, see The Quality Ceiling — same analogy-vibe, different scale.

References

1. RFC 6749 — The OAuth 2.0 Authorization Framework (IETF). https://datatracker.ietf.org/doc/html/rfc6749
2. OpenID Connect Core 1.0 specification. https://openid.net/specs/openid-connect-core-1_0.html
3. RFC 7519 — JSON Web Token (JWT) (IETF). https://datatracker.ietf.org/doc/html/rfc7519
4. NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management. https://pages.nist.gov/800-63-3/sp800-63b.html