Audience binding and constrained delegation

A resource service must apply the validation rules for the token type it accepts, including issuer, audience, time, algorithm, and relevant subject or scope constraints. Do not accept every signed JWT as an API access token. An OpenID Connect ID Token is intended for a relying party's authentication context and is not automatically a bearer access token for an unrelated resource API. A token's audience claim is meaningful only when the recipient compares it with the audience it is configured to accept.

Multiple audiences and token types need explicit policy, not a substring match on a service name. Validate identifiers according to their format and avoid treating an attacker-supplied key URL as an authority-selection shortcut. A token intended for service A should not gain acceptance at service B merely because both trust the same issuer. Audience is one necessary boundary; it does not by itself define the actions or resources that an authenticated subject may access.

A service may possess credentials that permit broad backend access while exposing a narrow user-facing operation. If it blindly forwards a caller-selected resource under its own identity, it can become a confused deputy. Bind the request to the caller's allowed resource and action, or use an explicit delegated credential whose authority is appropriately constrained. A trustworthy service identity tells the backend which service called; it does not automatically preserve the originating user's permissions.

OAuth token exchange can express subject and actor relationships under a defined issuer policy. Exchange does not inherently mean downscoping, one-time use, or revocation of the original token. The authorization server must enforce which callers may exchange which evidence for which audiences and permissions. Preserve audit context for both represented subject and acting service when the protocol supplies it. Avoid logging the exchanged tokens themselves, since ordinary bearer artifacts can be replayable during validity.

Present a token intended for another service and verify rejection before the business operation runs. Then test a valid caller token with a forbidden resource, action, or tenant. Exercise an exchange request asking for more scope than the policy permits, and inspect issued claims and backend decisions. Include cache keys and authorization caches: reusing a decision across audiences or caller contexts can undo correct token validation at the entry point. Return useful rejection diagnostics without exposing complete credentials.

The vectors lab is an explicit contrast with permission composition. Reset and set both angle 0, magnitude 2, predict(2,0), then inspect; Reset and re-set angle 90, magnitude 2 to predict(0,2). Geometric projections are not scopes, token audiences, or a cryptographic proof. In particular, adding two vectors is not how authority should be combined. Use the example to explain why a deputy should enforce a set intersection and recipient checks rather than simply add its own powers to the caller's request.