# Security Tests — Auth & Claims

**Task**: AZ-581_test_security_auth_claims
**Name**: Security tests — auth & claims (NFT-SEC-01..06 + 04b)
**Description**: Implement xUnit blackbox tests for the 7 JWT authn/authz scenarios — missing/invalid header, invalid signature (single-byte flip + foreign-keypair), expired-outside-skew vs inside-30s-skew, wrong `iss`, wrong `aud`, missing `permissions`, wrong/multi-value `permissions` claim (contains-match accepts `["FL","ADMIN"]`).
**Complexity**: 5 points
**Dependencies**: AZ-576_test_infrastructure
**Component**: Blackbox Tests
**Tracker**: AZ-581
**Epic**: AZ-575

## Problem

JWT validation is the only thing standing between the open `e2e-net` and the protected `/vehicles` + `/missions` + `/missions/{id}/waypoints` surface. Six failure modes (no header / bad signature / expired / wrong iss / wrong aud / wrong perm) MUST all produce `401` or `403` deterministically — any drift means an attacker who learns the JWKS public bytes could shape a token that bypasses one rule and rides through. The drift re-verification of 2026-05-14 split AC-5.3 into two checks (`iss` AND `aud`) and tightened the clock skew from .NET's 5-min default to 30s; this task pins both. NFT-SEC-06 specifically asserts the `RequireClaim("permissions","FL")` is contains-match — a multi-permission token `["FL","ADMIN"]` must be accepted, while `"fl"` / `"FLight"` / `"ADMIN"` alone must be rejected.

## Outcome

- All seven NFT-SEC-01..06 + 04b scenarios run and pass against the dockerised `missions` service.
- Each test produces a CSV row with `Category=Sec`, `Traces=AC-5.x` or `AC-9.x`, `Result=pass`.
- NFT-SEC-02 covers BOTH the single-byte-flip case AND the foreign-keypair case (token signed by a separate ECDSA keypair never published in the JWKS).
- NFT-SEC-03 verifies the 30s skew BOTH ways — `exp_offset_seconds=-60` rejected, `exp_offset_seconds=-15` accepted.
- NFT-SEC-06 verifies multi-permission token acceptance — `permissions: ["FL","ADMIN"]` → `200`.
- NFT-SEC-01 asserts no DB side-effect on the `POST /vehicles` 401 path (side-channel count unchanged).

## Scope

### Included

- NFT-SEC-01 Missing `Authorization` header on `/vehicles` GET/POST, `/missions` GET, `/missions/{any}/waypoints` GET — all `401`, no DB row written on the POST.
- NFT-SEC-02 Invalid signature — single-byte-flipped signature segment AND foreign-keypair tokens.
- NFT-SEC-03 Expired token — `exp_offset_seconds=-60` → `401`; `exp_offset_seconds=-15` → `200` (inside 30s skew).
- NFT-SEC-04 Wrong `iss` — `POST /sign { "iss": "https://attacker.example.com" }` → `401`; default `iss` → `200`.
- NFT-SEC-04b Wrong `aud` — `POST /sign { "aud": "wrong-audience" }` → `401`.
- NFT-SEC-05 Missing `permissions` claim — `403`.
- NFT-SEC-06 Wrong `permissions` value AND multi-permission acceptance — `"fl"`, `"FLight"`, `"ADMIN"` → `403`; `["FL","ADMIN"]` → `200`.

### Excluded

- NFT-SEC-07 health-exempt-from-auth lives in Task 15.
- NFT-SEC-08 stacktrace-not-leaked overlaps with FT-N-08 in Task 13 (and lives in Task 15 for the security-shaped variant).
- NFT-SEC-09 SQL injection guard lives in Task 15.
- NFT-SEC-10 alg-pin lives in Task 15.
- NFT-SEC-11 unknown-kid rotation lag lives in Task 15.
- NFT-SEC-12 missing-env startup throw lives in Task 15.
- NFT-SEC-13 CORS Production-gate lives in Task 15.

## Acceptance Criteria

**AC-1: NFT-SEC-01 missing header rejects every protected endpoint with 401, no side-effect**
Given the running test stack
When the consumer issues `GET /vehicles`, `GET /missions`, `GET /missions/{any}/waypoints`, and `POST /vehicles` with a valid body — all without an `Authorization` header
Then each response is `401`, AND side-channel `SELECT COUNT(*) FROM vehicles` before and after the `POST` are equal

**AC-2: NFT-SEC-02 invalid signature rejects two attack shapes**
Given a valid signed token `T_good` from `jwks-mock POST /sign`
When the consumer flips a single byte in `T_good`'s signature segment producing `T_bad`, and separately mints `T_foreign` signed by an ECDSA keypair never published in the JWKS
Then `GET /vehicles` with `T_bad` returns `401` AND `GET /vehicles` with `T_foreign` returns `401`

**AC-3: NFT-SEC-03 30s clock skew is enforced on both sides**
Given the mock with default issuer/audience
When the consumer mints two tokens via `POST /sign { exp_offset_seconds: -60 }` and `POST /sign { exp_offset_seconds: -15 }`
Then `GET /vehicles` with the −60s token returns `401` AND `GET /vehicles` with the −15s token returns `200`

**AC-4: NFT-SEC-04 wrong `iss` rejected, matching `iss` accepted**
When the consumer mints a token via `POST /sign { iss: "https://attacker.example.com" }` and another via `POST /sign {}` (default iss)
Then `GET /vehicles` with the attacker-iss token returns `401` AND with the default-iss token returns `200`

**AC-5: NFT-SEC-04b wrong `aud` rejected**
When the consumer mints a token via `POST /sign { aud: "wrong-audience" }`
Then `GET /vehicles` returns `401`

**AC-6: NFT-SEC-05 missing `permissions` claim rejected with 403**
When the consumer mints a token with no `permissions` claim (mock body `{ permissions: "" }` or `{ permissions: null }` per the mock's contract)
Then `GET /vehicles` returns `403` (NOT 401 — signature is valid)

**AC-7: NFT-SEC-06 contains-match policy on `permissions`**
When the consumer mints tokens with `permissions` values `"ADMIN"`, `"fl"` (lowercase), `"FLight"`, AND `["FL","ADMIN"]` (multi-value array)
Then `GET /vehicles` returns `403` for the first three AND `200` for the multi-value `["FL","ADMIN"]` array (contains-match accepts `"FL"` among the values)

## Non-Functional Requirements

**Performance**
- NFT-SEC-01..06: ≤ 5s each. The Authorization-header failure paths are cheap (no DB round-trip on the 401/403 short-circuit).

**Reliability**
- NFT-SEC-02 requires an out-of-band ECDSA-keypair helper that lives inside the test project, NOT in `jwks-mock` (the mock must never publish a public key it does not control). The helper generates a P-256 keypair at test-start and signs a token directly using `System.Security.Cryptography.ECDsa` — the public key is never registered with `missions`.

## Blackbox Tests

| AC Ref | Initial Data/Conditions | What to Test | Expected Behavior | NFR References |
|--------|------------------------|-------------|-------------------|----------------|
| AC-1 | running stack | 4 endpoints w/o Authorization | all 401; POST no DB write | AC-5.4 |
| AC-2 | `T_good` from mock + foreign keypair | flipped signature; foreign-keypair token | both 401 | AC-5.5 |
| AC-3 | mock with default iss/aud | exp_offset −60s vs −15s | 401 / 200 | AC-5.2, AC-5.6 |
| AC-4 | mock | iss=attacker vs default | 401 / 200 | AC-5.3, AC-5.11 |
| AC-5 | mock | aud=wrong | 401 | AC-5.3, AC-5.12 |
| AC-6 | mock | permissions missing | 403 | AC-5.8, AC-9.1 |
| AC-7 | mock | permissions=ADMIN/fl/FLight/["FL","ADMIN"] | 403/403/403/200 | AC-9.1, AC-9.2 |

## Constraints

- HTTP only against `http://missions:8080`. Tokens minted via `https://jwks-mock:8443/sign` with parameterised overrides.
- NFT-SEC-02 foreign-keypair: a test-only helper inside `Azaion.Missions.E2E.Tests` MAY use `System.Security.Cryptography.ECDsa` directly for the attack-token construction; this is the ONLY in-test signing path allowed — every other test must use the mock.
- NFT-SEC-06 multi-permission token requires the mock's `POST /sign` body to accept `permissions` as either a string OR a JSON array; the test-infrastructure ticket (AZ-576) covers this in the mock's contract.
- AAA pattern with `// Arrange` / `// Act` / `// Assert` per test.

## Risks & Mitigation

**Risk 1: NFT-SEC-03 flaky due to wall-clock variability**
- *Risk*: A −15s offset could fail if Docker time skew between the mock and `missions` is large.
- *Mitigation*: Both containers run on the same host clock (no `--init` time isolation); test asserts only at offsets well clear of the 30s boundary (−60s and −15s — 30s and 15s away from the boundary respectively).

**Risk 2: NFT-SEC-06 multi-permission shape varies between systems**
- *Risk*: If the spec for `permissions` claim later changes from "contains-match string" to "exact-array-membership", the multi-value assertion breaks.
- *Mitigation*: Test traces explicitly to AC-9.2 and references `Auth/JwtExtensions.cs` policy registration; any change there must update this test in the same commit.

**Risk 3: Foreign-keypair token validation might pass if the SUT silently trusts any well-formed ECDSA token**
- *Risk*: A regression that disables `IssuerSigningKeyResolver` would let the foreign-keypair token through.
- *Mitigation*: Mitigated by the structure of AC-2 — both bad-signature shapes (flipped byte AND foreign keypair) must return 401.

## System Under Test Boundary

- Tests drive the product through the public HTTP surface (`http://missions:8080/{vehicles,missions}*`) and acquire signed tokens via `https://jwks-mock:8443/sign` (with the test-only foreign-keypair helper for NFT-SEC-02). Expected outputs are the documented HTTP status codes from `_docs/00_problem/input_data/expected_results/results_report.md` AC-5 rows and AC-9 rows.
- Stubs are allowed ONLY for: the external `admin` JWT issuer (`jwks-mock` container).
- Stubs, fakes, deterministic fallbacks, monkeypatches, or direct imports are NOT allowed for any internal product module — including `JwtExtensions`, `Program.cs` (auth pipeline registration), the `[Authorize(Policy = "FL")]` filter, or `ErrorHandlingMiddleware`. If any of these is not implemented, the test MUST fail/block as missing product implementation — it must not pass by replacing the module with a test stub.