The Problem With Sharing the Key
Before Pramanik built the delegation system, the only way for Lekhankar to access Grameen's land records was for Grameen to hand over his password. The clerk-application would log in as the farmer. The farmer had no way to limit what the clerk could do — with the password, the clerk could do anything. The farmer had no way to revoke access to just the clerk without changing his password everywhere. If the clerk-application was compromised, the attacker had the farmer's full credentials. This was the problem OAuth 2.0 was designed to solve: resource owners should grant limited, revocable, scoped access to third parties without sharing their primary credentials.
“Never share primary credentials to grant limited access. Delegation must be scoped and independently revocable.”
The Consent Ceremony
Under the new system, when Lekhankar needed to access Grameen's records, it did not ask for the password. Instead, it redirected the farmer to Pramanik's office — the authorization server. Pramanik showed Grameen a clear scroll: "Lekhankar is asking to read your land records for thirty days. Do you consent?" Grameen signed the scroll. Pramanik then gave Lekhankar an access token — not the farmer's password, but a limited, time-bound instrument that proved Bhoomipala should allow read access to Grameen's records for thirty days. Lekhankar never saw the farmer's password. The farmer's consent was recorded. The access could be revoked by cancelling the token without changing any password.
“OAuth 2.0 separates authentication (Pramanik) from authorization (the token). The application gets a token, never the credential.”
The Unsafe Messenger and the Stolen Code
In the early days, Lekhankar received the authorization code directly in a URL parameter — the code would travel in the web address, where it could be observed by Grameen's neighbour, who watched the road. A new safeguard was introduced: before starting the journey, Lekhankar created a secret random phrase, hashed it, and sent the hash to Pramanik with the initial request. When Lekhankar returned with the authorization code, it also proved it held the original phrase by presenting it unhashed. Pramanik would hash it and confirm the match. Even if the neighbour stole the authorization code from the road, she could not exchange it for a token without knowing the original secret phrase. This is PKCE — Proof Key for Code Exchange.
“PKCE prevents authorization code interception. Use it for all OAuth flows, especially public clients like SPAs and mobile apps.”
The Layer Above: Who is This Person?
OAuth 2.0 answered only: "Can Lekhankar access this resource?" It said nothing about who the farmer actually was. A second layer was added on top of OAuth 2.0: OpenID Connect. When Lekhankar requested access, it could additionally ask: "And please also tell me who this person is." Pramanik would issue not just an access token but also an ID token — a JWT whose payload contained verified facts about the user: their identifier, name, email, and when the authentication happened. The access token spoke to resource servers. The ID token spoke to the client application about identity. The two tokens had different audiences and different purposes. Using them interchangeably was an error. Using an access token as proof of identity was a mistake applications made too often.
“OAuth 2.0 is authorization. OpenID Connect adds identity. Use the ID token to know who the user is; use the access token to access resources.”
The Scopes That Limit the Damage
When Grameen reviewed his delegation records, he found that a dozen clerk-applications had been granted access over the years. Some had asked for "read:everything." He could not remember approving that scope. He asked Pramanik to cancel every token. But if each application had requested only the scope it truly needed — "read:land-records" instead of "read:everything" — the damage from any one compromised application would have been contained. Pramanik introduced minimum-scope reviews: every application was required to justify the scopes it requested. An application requesting more than it needed was rejected. The principle of least privilege applied to delegated access as much as it applied to any other system.
“Request only the minimum scopes needed. Least-privilege delegation limits damage when any one token or application is compromised.”
🪔 Deepak — the lamp of meaning · what this fable means in code
OAuth 2.0 is an authorization framework, not an authentication protocol. Flows: Authorization Code (with PKCE for all clients), Client Credentials (service-to-service, no user), Device Code (TV/CLI). Never use Implicit flow. PKCE replaces client secrets for public clients — the code_verifier is random, the code_challenge is SHA-256(code_verifier), sent with the auth request; the verifier is sent at token exchange. OpenID Connect adds an ID token (JWT with user identity claims) on top of OAuth 2.0. Key claims: "sub" (user identifier), "iss" (issuer), "aud" (audience), "nonce" (replay protection). Always validate ID token signature, issuer, audience, and expiry. Access tokens and ID tokens have different audiences — never use an access token as proof of identity. Request minimum scopes. Implement token introspection or JWT validation at the resource server.