The test fixture
Suppose a scheduled worker reads overdue invoice IDs from a ledger and creates a daily summary. It has one identity, a credential with a bounded lifetime, and permission to read invoices. A second internal service handles billing changes. Both services trust the same issuer. That shared issuer does not make a credential issued for billing valid at the ledger.
Follow three separate decisions
- Can I trust this credential? The receiver checks the signature or equivalent proof, issuer, lifetime and other requirements for this credential type. In the lab this is an input, not a cryptographic test.
- Was it issued for this receiver? Check the intended audience. A string that looks like a service ID is not sufficient; compare under the policy for the actual resource server.
- May this principal do this to this object? Read permission does not imply write permission, nor does access to one tenant imply access to another. Enforce object-level authorization at the resource.
Reproduce a failure before deployment
Run the authorized read preset, then change only the audience to billing-api. The outcome must become DENY while the action and URL checks still pass. Reset the audience, request invoice:write, and check that the permission gate independently refuses it. Finally expire the credential. Three distinct failures demonstrate that the controls are not accidentally substituting for each other.
What evidence to keep
Use a short decision ID and stable rule names in operational records. Record which check failed and which workload class was affected; do not log bearer credentials. In a real system, repeat the test against the receiving service itself. A green local model says nothing about whether a proxy or another endpoint bypasses the policy.
References: OWASP Authorization Cheat Sheet and IETF OAuth 2.0 Security Best Current Practice.