Two bindings
The issuer identifies the authority that created and signs or vouches for a token. The audience or resource identifies the service permitted to accept it. A valid signature without both bindings can let one tenant, authorization server, or resource accept authority intended for another.
Validate from configuration
Select trusted issuer metadata from configuration or a bounded discovery process. Verify the exact issuer, signature and algorithm, audience or resource, token type, time, and required client or subject. The resource server must know its own accepted audience. Do not let an unverified token claim choose its key source or trust anchor.
Keep resource specific
Request and issue tokens for a named resource where the protocol supports it. The resource server then applies scopes and local permission. Reject a token intended for another API even when the same issuer and subject are trusted.
Failure and residual risk
Issuer mix-up, wildcard audiences, shared signing keys, unbounded discovery, and token passthrough create cross-service authority. An audience match does not prove object permission. A valid token can be replayed if it remains a bearer credential.
Pomerium boundary
Pomerium validates tokens it is configured to accept and applies route policy. Applications that accept their own OAuth tokens must validate issuer, audience, token status, and local permission. A Pomerium identity assertion also needs an intended upstream and trusted validation path.
Evaluation checklist
- Is the trusted issuer fixed or discovered through a bounded rule?
- Does the resource server compare the token audience with its own identity?
- Can a token from another tenant, issuer, client, or API be rejected?
- Is the verification key source independent of untrusted token claims?
- Does local object and action authorization follow token validation?
