Authorization 與 authentication 的差別

Two Different Questions

Security systems ask two separate questions. Mixing them up causes real bugs.

Authentication asks: Who are you? It proves identity, like checking a password or a face.

Authorization asks: What are you allowed to do? It grants permission to specific actions or data.

OAuth 2.0 is built to answer the second question. That surprises many developers.

The Hotel Key Card

Picture a hotel key card. It opens room 204 and the gym, nothing else.

The door does not check your name. It only checks whether the card carries permission for that room.

Notice the lock only reads the card, so it lets in whoever is holding it without knowing their name.

Whoever holds the card gets in. The card proves access rights, not who you are.

An OAuth access token works the same way.

How OAuth 2.0 Grants Access

OAuth 2.0 lets you give an app limited access to your data without handing over your password.

You approve a request, and the app receives an access token.

The app shows that token to an API. The API checks one thing: does this token include the needed scope?

Nothing in that check asks who is using the app.

What a Token Proves

A scope is a named permission, such as reading a calendar or posting on your behalf.

An access token says: the bearer may do these things. That is a permission range.

It does not reliably say this is Alice, right now. The API only needs to know what is allowed.

Treat the token as a permission slip.

Using OAuth for Login

A common mistake: an app gets an access token and treats it as proof of login.

That confuses authorization with authentication. The token shows permission, not a verified person.

If you need identity, add an identity layer. OpenID Connect sits on top of OAuth 2.0 and issues an ID token describing the user.

Ask first which question you need answered.

A Token Anyone Can Use

Remember the key card: whoever holds it gets in.

Access tokens are often bearer tokens. The API trusts whoever presents them.

So if a token leaks, the API still sees valid permission. It has no idea the holder changed.

This is why identity must come from somewhere else.

Key Takeaways

When you see OAuth 2.0 in a design, ask what it is really proving.

Access token means permission. ID token means identity.

Explain it to a colleague like this: OAuth answers what can this app do, not who is this person.

Checking scopes protects APIs. Confirming identity needs authentication.

When a system checks a user's password to confirm they are really Alice, it is performing _____

• authentication
• authorization

Answer: authentication

Verifying a password proves identity, which answers Who are you? That is authentication. Authorization answers a different question: What are you allowed to do?

In an OAuth-based design, an _____ carries permission to call an API. An _____, issued by OpenID Connect, describes the user. Each named permission inside the first token is called a _____.

Answer: In an OAuth-based design, an access token carries permission to call an API. An ID token, issued by OpenID Connect, describes the user. Each named permission inside the first token is called a scope.

An access token means permission, and its permissions are expressed as scopes, such as reading a calendar. An ID token comes from OpenID Connect, which sits on top of OAuth 2.0 and describes who the user is.

An app presents an OAuth access token to a calendar API to read events. What does the API essentially need to verify before allowing the request?

• That the token includes the scope for reading the calendar
• That the person using the app is the account owner right now
• That the user re-entered their password for this request
• That the token contains the user's verified name and email

Answer: That the token includes the scope for reading the calendar

The API checks one thing: does the token include the needed scope, here reading the calendar? It does not ask who is using the app. Like a hotel key card, the door checks permission for the room, not the holder's name.