At the Four Seas Inn south of the imperial capital of Lin’an, hundreds of merchant travelers passed through the timber gates each day.

For decades, the venerable innkeeper adhered to an unbroken convention: upon check-in, the front desk bestowed a heavy brass key upon the guest. This key turned the engraved mortise lock of Room Two on the upper floor, and in the crisp dawn, presenting it to the kitchen apprentices entitled the bearer to a kettle of piping hot water and fresh linen.

One spring afternoon, Lu Xiu, a young silk merchant from Huzhou, carried this brass key across town to the Wansheng Tea House, seeking to seal a contract for ten thousand taels of silver. Master Li, the seasoned proprietor of the tea house, inspected the raw silk samples with satisfaction. But before wetting his brush with ink, he leveled a piercing gaze at the young traveler: “Young Master Lu, your merchandise is flawless, yet we have never broken bread before. Before I stamp this agreement, I require an official seal of identity proving that you are indeed the eldest heir of the venerable Lu clan. How else could I entrust ten thousand taels of silver to an unfamiliar hand?”

Lu Xiu rummaged through his embroidered sleeves and produced the heavy brass key of the Four Seas Inn, sliding it across the cypress table: “Master Li, pray inspect this. This is the key to the finest guest room at the Four Seas Inn. The innkeeper has seen emperors and ministers; would he entrust Room Two to any common drifter?”

Master Li scrutinized the piece of forged metal and broke into a quiet chuckle: “Young Master, this key only proves you can turn the brass tumblers of a lock on the second floor of the Four Seas Inn. Does it bear your surname? Does it record your ancestral home? If an errand boy swiped it from your washbasin an hour ago, or if a highwayman found it in the gutter, it would turn that same lock just as easily. How can an instrument meant solely for turning locks testify to the living soul standing before me?”

Master Li leaned forward, his voice dropping: “What is worse: were I to accept this key and send my apprentice to verify it at the inn, he could effortlessly slip into your bedchamber and plunder your silk chests bare. In using a key to prove your identity, you have unwittingly surrendered the power to strip your rooms!”

The very next day, the Imperial Ministry of Revenue promulgated an imperial decree to rectify such perilous confusions across the capital. From that hour forward, all traveling merchants were required to carry two distinct credentials:

The first was the Carved Jade Passport (The ID Token). Quarried from white mutton-fat jade, it bore the official vermillion seal of the Ministry. Upon its polished face, three truths were carved in deep relief: that it was issued by the Imperial Ministry, that the subject was Lu Xiu of Huzhou, and that it was crafted solely for the inspection of Master Li at Wansheng Tea House. Beneath these ran a precise timestamp and an intricate counter-fraud cipher. Master Li had only to inspect the jade plaque against the morning sun, verify the cinnabar seal with his own eyes, and instantly establish the identity of the young merchant. The jade plaque possessed no notches, fitted no lock, and even if held by a thief, could not budge a single wooden latch.

The second was the familiar Brass Key (The Access Token). When Lu Xiu required a hired porter to retrieve silk spools from the inn, he never surrendered his jade plaque. He handed the brass key to the porter. The innkeeper and kitchen staff recognized the key without demanding genealogies; the porter turned the lock, gathered the requested bolts, and departed. The innkeeper never questioned the porter’s bloodline, and the porter, key in hand, could never march into the Magistrate’s hall pretending to be the master of the Lu estate.

Ever after, the merchants of Lin’an lived by an inviolable maxim: “The Jade Passport verifies who you are (Authentication); the Brass Key unlocks what you may touch (Authorization). To present a door-key as proof of pedigree is to invite thieves into your home; to thrust a jade genealogy into a lock-tumbler is to shatter your own name.”

— — —

What it is

By now the architecture is unmistakable: this is the classic, vital distinction at the foundation of modern distributed identity: OAuth 2.0 versus OpenID Connect (OIDC).

OAuth 2.0 was conceived purely as an authorization framework for delegated access. It was engineered to solve one problem: allowing a resource owner to delegate restricted access to an application via an Access Token (the brass room key). The client presents this token to a Resource Server (API) to retrieve data. The Access Token is a bearer credential: the API verifies whether the token has the requisite permissions (scopes), entirely indifferent to who originally presented it. In the early days of the web, developers dangerously abused Access Tokens as pseudo-identity passes—inferring that if a client could fetch an email address with a token, the user was authenticated. This misconception fostered devastating security vulnerabilities, including Confused Deputy and Token Substitution attacks.

To resolve identity once and for all, the security community built a dedicated identity authentication layer atop OAuth 2.0: OpenID Connect (OIDC). OIDC introduced an entirely separate artifact: the ID Token (the carved jade passport). The ID Token is a cryptographically signed JSON Web Token (JWT) issued by an Identity Provider (IdP) for direct consumption by the client application. It contains standardized identity assertions (claims):

• iss (Issuer): The trusted identity authority that minted the token;
• sub (Subject): The globally unique, immutable identifier for the authenticated user;
• aud (Audience): The specific client application for which this token was minted (matching its registered client_id);
• iat & exp: Precise issued-at and expiration timestamps;
• nonce: A cryptographic string binding the request to prevent replay attacks.

Why it matters

Maintaining a rigorous separation between ID Tokens and Access Tokens is an absolute prerequisite of Zero Trust architecture:

1. Audience and Consumer Segregation: The sole intended consumer of an ID Token is the client application itself. The client validates its signature, audience, and nonce locally to establish a user session. The client must never send the ID Token to a downstream resource API. Conversely, the consumer of an Access Token is the resource server (API). The client treats it as an opaque credential, merely relaying it in the Authorization: Bearer header.
2. Elimination of Token Substitution Attacks: Before OIDC, an attacker could authorize with a malicious app, intercept their own Access Token, and send it to a victim application. If the victim app trusted any valid token to establish identity, the attacker could hijack user accounts. With OIDC, every ID Token carries an explicit aud claim pointing strictly to the client that requested it. A token minted for App A will be rejected on sight by App B.
3. Stateless, Low-Latency Local Verification: Clients download the IdP’s public keys (JWKS) once and verify ID Token signatures locally in microseconds. This eliminates synchronous round-trips to remote /verify_token endpoints on every user action, removing a notorious architectural bottleneck while fortifying security.

Metaphor mapping

• Brass room key → OAuth 2.0 Access Token (Delegated capability to invoke protected APIs)
• Carved white jade passport → OIDC ID Token (Signed JWT proving the verified identity of the user)
• Ministry of Revenue Registrar → Identity Provider (IdP, e.g., Okta, Auth0, Keycloak)
• Master Li of Wansheng Tea House → Relying Party / Client Application
• Inn room lock and silk chests → Resource Server / Protected API
• Jade carving specifying “For Master Li” → The audience claim (aud = client_id) in the ID Token
• Cinnabar imperial seal and cipher → Cryptographic JWT signature and anti-replay nonce
• Hired porter using the key to fetch silk → Client presenting Access Token to access resource endpoints
• Presenting a room key to prove ancestry → Pseudo-authentication vulnerability using Access Tokens