Resource Indicators: Binding Tokens to a Specific API

Fri, 26 Jun 2026 00:00:00 +0000

Why a generic access token is not enough #

v08 replaced the shared JWT_SECRET with RS256 + JWKS. Verifiers fetch public keys and check signatures. That fixed the question of who can forge tokens.

It did not fix the question of where a token may be used.

In v08, Mode B access tokens carry a hard-coded audience:

{ "aud": "resource-server", "iss": "auth-server", "sub": "user0" }

That string is a lab placeholder, not a real resource binding. Any API that knows to expect aud: resource-server would accept the token. In production there can be dozens of APIs behind one IdP (payments, calendar, internal admin tools), each with its own canonical URI. A token minted for one API should not work against another, even when both trust the same issuer.

Resource-Indicators on Sauvik Biswas

Resource Indicators: Binding Tokens to a Specific API

Why a generic access token is not enough #