A security architecture should be judged by rejection behavior, not only by a successful demonstration. Each test below states a precondition, an enforcement point, and evidence to collect. The exact HTTP status or OAuth error depends on the failing stage and implementation; do not require a universal error code where the standards or product do not prescribe one.
Test environment and positive controls
Use isolated non-production identities and resources. Establish a successful standalone call and a successful Lisa/XYZ delegated call first. Capture the issued token’s approved claims without copying credentials into ordinary logs. Confirm the actual policy version and key material in use. Change one condition per test where possible, and retain request correlation so failures can be attributed to the intended control.
Where a deployment does not implement a proposed control, mark the corresponding test as an identified gap or accepted risk, not a false pass. Sender-constraint tests require a genuinely supported profile. Task-authorization tests require the resource server to implement that policy.
| ID | Input or precondition | Enforcement point | Expected outcome/evidence |
| 01 | Actor token from untrusted issuer | STS actor validation | Reject; log issuer-policy failure |
| 02 | Actor JWT-SVID with wrong STS audience | STS actor validation | Reject; intended-recipient failure |
| 03 | Human JWT substituted as actor evidence | STS profile validation | Reject; cross-profile failure |
| 04 | Workload JWT substituted as human subject | STS subject validation | Reject; subject-profile failure |
| 05 | Unsigned or disallowed-algorithm JWT | STS/API signature policy | Reject; algorithm/signature failure |
| 06 | Token with attacker-controlled key URL | Configured key-resolution boundary | No outbound trust in supplied URL; reject invalid signature |
| 07 | Expired input token | STS time validation | Reject; expiration failure |
| 08 | Input not yet valid outside allowed skew | STS time validation | Reject; temporal-policy failure |
| 09 | Output token presented to wrong API | Resource audience validation | Reject; audience mismatch |
| 10 | Forged act claim on signed token | Resource signature validation | Reject; modified token |
| 11 | Caller actor override differs from verified identity | STS mapping/policy | Reject or ignore override under explicit policy; no forged attribution |
| 12 | Client/actor pairing forbidden by policy | STS relationship policy | Reject; pairing decision recorded |
| 13 | XYZ paired with ineligible Lisa delegation | STS approval/pairing policy | Reject; subject/actor eligibility failure |
| 14 | Unauthorized output audience requested | STS target policy | Reject; disallowed exchange edge |
| 15 | Scopes exceed approved grant | STS scope policy | Reject or explicitly downscope; record granted set |
| 16 | Missing actor on delegated-only API | API delegated-profile policy | Reject; required-actor failure |
| 17 | Malformed nested actor structure | STS/API schema validation | Reject; malformed identity context |
| 18 | Nested actor has privileged identity | API authorization engine | No privilege union; deny operation not allowed by top-level context |
| 19 | Valid token mutates wrong case | API object authorization | Reject; resource mismatch |
| 20 | Valid token changes forbidden field | API mutation authorization | Reject; actual-body constraint failure |
| 21 | Approval expired before exchange | STS approval service | Reject; stale grant |
| 22 | Approval revoked after token issuance | API current-grant control if configured | Reject within measured distribution/cache window |
| 23 | One-time authorization reused | API transactional grant control | No second mutation; atomic use evidence |
| 24 | Stolen bearer token presented elsewhere | Resource authentication | May succeed absent sender constraint; document residual risk |
| 25 | Wrong certificate for bound token | mTLS/token-binding verifier | Reject; certificate-thumbprint mismatch |
| 26 | Wrong DPoP key or token hash | DPoP-capable resource | Reject; proof/token binding failure |
| 27 | Replayed DPoP proof | DPoP replay/freshness verifier | Reject per deployed replay policy; proof evidence |
| 28 | Unknown kid during discovery outage | STS/API key validation | Reject unknown key; bounded refresh attempts |
| 29 | Planned key rollover with old/new tokens | STS/API verification caches | Valid intended tokens pass during planned overlap |
| 30 | Disabled actor uses cached valid JWT | Resource deny/revocation controls | Measure rejection latency; no unsupported instant-revocation claim |
| 31 | Workload does not match registration selectors | SPIRE workload issuance | No XYZ credential; attestation/issuance evidence |
| 32 | Unrelated pod chooses XYZ service account | Admission/RBAC plus SPIRE policy | Blocked deployment or deny issuance; otherwise record privilege gap |
| 33 | Unauthorized node attempts enrollment | SPIRE node attestation | No accepted eligible agent identity |
| 34 | Queued job runs after delegation revoked | Worker authorization boundary | Reject execution; log job and approval IDs |
| 35 | Tenant/resource identifier substitution | STS and resource tenant policy | Reject cross-tenant access |
| 36 | Policy/STS outage triggers retry fallback | Application/worker failure path | No anonymous or broader-authority fallback |
Acceptance criteria
- Every failure occurs at a documented boundary and emits useful non-secret audit evidence.
- No test silently changes a delegated request into impersonation or anonymous access.
- No requested audience or scope becomes trusted merely because it was requested.
- Resource-level constraints are checked against the actual operation and canonical object.
- Revocation and outage tests report measured windows, not assumed guarantees.
- Concurrent one-time execution tests demonstrate atomic behavior.
- Known valid controls still pass after policy tightening and planned key rotation.
Adversarial execution and evidence
Repeat tests with concurrency, stale caches, alternate replicas, and retrying workers. Exercise non-happy-path serialization and identifier normalization. Confirm that every API instance uses the same intended policy version. Capture both denial and business-state evidence: a rejected response is insufficient if a mutation occurred before the rejection.
Takeaway: a useful test report says where abuse was blocked, why, what residual exposure remains, and how quickly changes reach every enforcement point.