OAuth 2.0 and JWT Explained: What Really Happens When You Click "Sign In"

Part 2 of 19 · ~2 min

OAuth Is Authorization, Not Authentication

Start with the word itself, because it's the source of most of the confusion that follows. Strip away the acronym and what you're left with is a delegation protocol: a mechanism letting one piece of software borrow permission to act on a person's behalf against some other service, with that service never once handing over the person's actual credentials. Put another way, OAuth answers authorization — given that a client is asking, what should it actually be allowed to touch.

Working out who just clicked that button is a separate concern entirely, one the OAuth spec has nothing to say about. OpenID Connect (OIDC) is the spec that steps in to answer it — a comparatively small set of additions layered over plain OAuth 2.0, built around one specific new artifact it introduces: the ID token. Priya's login used both mechanisms in the same few seconds, for two genuinely different reasons — OAuth so Tasklight is allowed to call Kestrel's People API on her behalf, OIDC so Tasklight gets back something it can actually trust as proof of which person just authenticated.

Here's a way to tell the two apart in any real integration: follow what happens to the token immediately after it's issued. If it gets handed to an API — Kestrel's Calendar API, Tasklight's own tasks-service — that's OAuth doing its job. If it gets read by the client itself to decide whose name goes on the dashboard, that's OIDC. Tasklight's nightly reporting job is a clean example of pure OAuth with zero authentication in it anywhere: no person logs in, there's no "who" to establish, just one service proving to another that it's allowed to ask for a usage number. The moment Priya's own name shows up in the corner of her own screen, that's the OIDC half switching on.