Authentication
Why is OAuth not authentication?
A secret that travels is, at the moment it travels, held by two parties. This single fact produces the whole ladder of designs.
Take a password sent to a server. The server now holds the password, forever, for every service where the user reused it. There are three escapes, and they are the three directions in which every later design improves:
| Escape | Idea | Examples |
|---|---|---|
| 1. Do not transmit the secret | Prove you hold a key without showing it | challenge–response; asymmetric proof of possession (the server sends a random challenge, you sign it with your private key, the server checks with your public key) |
| 2. Transmit something worthless quickly | Make a captured credential decay | tokens with short lifetimes |
| 3. Bind the secret to a context | A copy shown to the wrong verifier or over the wrong connection fails | audience restriction (the token names the one service that may accept it); channel binding; mTLS (mutual TLS: both client and server present certificates) |
Bearer tokens: what they give up
The most common form in use is the bearer token: whoever bears (holds) it gets the access. It deliberately gives up escapes 1 and 3. Possession is identity; there is no proof that you are the party the token was issued to. People choose it because it is stateless to verify (the server checks a signature and an expiry, with no database lookup) and trivial to pass through proxies. The whole apparatus of scopes (which actions it allows), audiences (which service accepts it) and TTLs exists to make up for that choice.
OAuth is not an authentication protocol
OAuth solves a different problem: delegation without sharing a credential. Before OAuth, if a third-party app (say a calendar tool) needed to act on your behalf, you handed over your password. That gave the app full authority, permanently, and the only way to revoke it was to change your password, which broke everything else that used it.
OAuth inserts an authorization server that issues a narrower, expiring, independently revocable proof. The key rule: the resource owner's own credential never reaches the client.
OIDC (OpenID Connect) exists because people kept using OAuth's access token as evidence of who the user is. It is not. An access token proves that someone authorized access. It does not prove that the bearer is that someone. OIDC adds an identity token to correct this.
Workload identity: identity from where the code runs
This case matters most for data engineering, because it reverses the basis of identity. A human can hold a secret the host does not have (a memorized password, a hardware key). A process cannot. Any long-lived machine credential is a file on a disk, readable by anything that compromises that host, and rotating it means touching every host that has it.
So the only bootstrap that works is attestation by something the workload cannot forge: the scheduler, the hypervisor or the hardware. (Attestation means a trusted party signs a statement: "this exact program is running on this machine, in this job".) Identity is derived from where the code runs, not from what it knows. The secret that could not be protected is replaced by a position that cannot be faked, and the supplier of identity becomes the platform.
Example. A cloud scheduler starts a job. The job asks the platform for credentials; the platform checks that the request really comes from that job on that machine, and returns a token valid for 15 minutes. There is no password file to steal.
In one sentence: every credential is a secret in transit; the design space is only how short-lived, how narrowly scoped and how bound to context you can make it before verification becomes expensive.