"Sign in with Google" — so OAuth 2.0 is how you log in, right? Not quite.
THREE THINGS, OFTEN TREATED AS ONE
• Authentication — who are you? Proving identity.
• Authorization — what are you allowed to access? Granting permission.
• OAuth 2.0 — a framework for the second one: delegated access.
THE OAUTH 2.0 FLOW
You → Authorization Server → Access Token → API
1. The app sends you to the authorization server.
2. You sign in there (not in the app) and approve a specific scope —
"allow access to your photos."
3. The server issues the app an access token.
4. The app calls the API with that token.
The point of the whole dance: the app gets limited access to your data
without ever seeing your password. It can read the photos you approved —
and nothing else.
THE PART MOST EXPLANATIONS GET WRONG
An access token is a key, not an ID card. It says what the bearer may do.
It does not say who the bearer is, and it isn't addressed to the app —
it's addressed to the API.
So using an access token as proof of identity is a genuine security bug.
It's the root of the "confused deputy" problem: an app accepts a token,
assumes it identifies the user, and a token minted for a different app
gets accepted as a login.
FOR LOGIN, USE OPENID CONNECT
OIDC is a thin identity layer built on top of OAuth 2.0. It adds an
`id_token` — a signed JWT about *who the user is*, with an issuer, an
audience, and an expiry you verify. That's the thing designed to answer
"who are you."
In practice "Sign in with Google" is OIDC riding on OAuth 2.0. The two
tokens do different jobs:
access_token → what the app may do
id_token → who the user is
—
#Astmation — #software #systems , #automation , and #AI-powered #applications .
Build. Automate. Evolve.
https://astmation.com/
#Shorts #OAuth #OAuth2 #OpenIDConnect #Authentication #Authorization #WebSecurity #API #BackendDevelopment #SoftwareEngineering
Watch on YouTube