← ClaudeAtlas

auditing-oauth-token-audience-and-scope-trustlisted

Audit how a resource server trusts OAuth access tokens for confusion it should reject: a token minted for one audience accepted by a different service, a scope treated as coarser or finer than it is so a token reaches an operation it was not granted, a token-issuer or authorization-server mix-up where a token from one issuer is honored by a party that trusts another, and a resource server that validates the signature but not the audience, issuer, or scope. Covers OAuth and bearer-token architectures where an access token authorizes a call between a client, an authorization server, and one or more resource servers. Use when a resource server accepts bearer tokens and the audience, issuer, and scope checks are the boundary. The token presented to the wrong audience or beyond its scope is the source, the resource operation it reaches is the sink, and the missing audience, issuer, or scope validation is the bug.
UnboundCompute/security-agent-skills · ★ 4 · AI & Automation · score 80
Install: claude install-skill UnboundCompute/security-agent-skills
# Auditing OAuth token audience and scope trust: a token is only good for what it was issued for A bearer access token is a claim with a precise domain: it was issued by a particular authorization server, for a particular audience, carrying a particular scope, and it authorizes only what those three agree on. A resource server that checks the signature but not the audience, issuer, and scope is trusting a token far beyond what it was minted for. The confusions are specific and common. A token issued for service A is presented to service B, and if B does not verify the audience it accepts A's token as its own. A scope is treated as coarser than it is, or a missing-scope check lets any valid token reach a privileged operation. A token from a different authorization server is honored by a party that only meant to trust one issuer. Each is a token used outside its domain. The audit checks that every token is validated against the audience, issuer, and scope the operation requires, not merely that it is a well-formed, signed token. You audit this by testing whether a token good for one thing is accepted for another. ## When to use - A resource server accepts OAuth or bearer access tokens to authorize calls. - Multiple services or audiences accept tokens, and the audience or issuer may not be verified per service. - Scopes gate operations, and the resource server may not check the specific scope each operation requires. ## Scope check Test token trust only against services you