admin/_docs/02_document/tests/blackbox-tests.md

Blackbox Tests

Positive Scenarios

FT-P-01: Successful Login

Summary: User with valid credentials receives a JWT token. Traces to: AC-1 Category: Authentication

Preconditions:

• Seed user admin@azaion.com exists in database

Input data: Valid email/password for seed admin user

Steps:

Step	Consumer Action	Expected System Response
1	POST /login with valid email and password	HTTP 200, body contains non-empty token string

Expected outcome: HTTP 200 with JWT token in response body Max execution time: 5s

---

FT-P-02: Successful User Registration

Summary: ApiAdmin creates a new user account. Traces to: AC-5, AC-6, AC-7 Category: User Management

Preconditions:

• Caller authenticated as ApiAdmin

Input data: {"email":"newuser@test.com","password":"validpwd1","role":"Operator"}

Steps:

Step	Consumer Action	Expected System Response
1	Login as admin to get JWT	HTTP 200, JWT token
2	POST /users with valid registration data and ApiAdmin JWT	HTTP 200

Expected outcome: HTTP 200, user created Max execution time: 5s

---

FT-P-03: JWT Token Structure Validation

Summary: JWT token contains correct issuer, audience, and lifetime claims. Traces to: AC-4 Category: Authentication

Preconditions:

• Valid login completed

Input data: JWT token from login response

Steps:

Step	Consumer Action	Expected System Response
1	Login to get JWT	HTTP 200, JWT token
2	Decode JWT payload (Base64)	Claims contain iss, aud, exp
3	Validate iss == "AzaionApi"	Match
4	Validate aud == "Annotators/OrangePi/Admins"	Match
5	Validate exp - iat ≈ 14400s (4 hours)	Within ± 60s

Expected outcome: All JWT claims match expected values Max execution time: 5s

---

FT-P-04: First Hardware Check Stores Fingerprint

Summary: On first hardware check, the fingerprint is stored for the user. Traces to: AC-10 Category: Hardware Binding

Preconditions:

• User exists with no hardware bound

Input data: {"hardware":"test-hw-fingerprint-001"}

Steps:

Step	Consumer Action	Expected System Response
1	Register new user, login to get JWT	HTTP 200
2	POST /resources/check with hardware string	HTTP 200, body true

Expected outcome: HTTP 200, hardware stored Max execution time: 5s

---

FT-P-05: Subsequent Hardware Check Matches

Summary: Same hardware fingerprint passes validation on subsequent calls. Traces to: AC-11 Category: Hardware Binding

Preconditions:

• User with hardware already bound (from FT-P-04)

Input data: Same hardware string as initial binding

Steps:

Step	Consumer Action	Expected System Response
1	POST /resources/check with same hardware	HTTP 200, body true

Expected outcome: HTTP 200 Max execution time: 5s

---

FT-P-06: List All Users

Summary: ApiAdmin retrieves the user list. Traces to: AC-9 Category: User Management

Preconditions:

• Caller authenticated as ApiAdmin

Input data: GET /users with ApiAdmin JWT

Steps:

Step	Consumer Action	Expected System Response
1	GET /users with ApiAdmin JWT	HTTP 200, JSON array with >= 1 user

Expected outcome: HTTP 200, array containing at least seed users Max execution time: 5s

---

FT-P-07: Filter Users by Email

Summary: ApiAdmin filters users by email substring. Traces to: AC-9 Category: User Management

Preconditions:

• Caller authenticated as ApiAdmin, seed users exist

Input data: GET /users?email=admin

Steps:

Step	Consumer Action	Expected System Response
1	GET /users?email=admin with ApiAdmin JWT	HTTP 200, all returned emails contain "admin"

Expected outcome: HTTP 200, filtered list Max execution time: 5s

---

FT-P-08: Upload Resource File

Summary: Authenticated user uploads a file to a resource folder. Traces to: AC-13 Category: Resource Distribution

Preconditions:

• Caller authenticated

Input data: Multipart form upload with 1 KB text file

Steps:

Step	Consumer Action	Expected System Response
1	POST /resources/testfolder with multipart file	HTTP 200

Expected outcome: HTTP 200, file stored Max execution time: 5s

---

FT-P-09: Download Encrypted Resource — OBSOLETE (cycle 2, 2026-05-14)

The POST /resources/get/{dataFolder?} endpoint, the Security.GetApiEncryptionKey / EncryptTo helpers, the ResourcesService.GetEncryptedResource method, the GetResourceRequest DTO, and the e2e tests Encrypted_download_returns_octet_stream_and_non_empty_body (in ResourceTests.cs) and Per_user_encryption_produces_distinct_ciphertext_for_same_file (in SecurityTests.cs) were all removed. The endpoint now returns 404 — verified by FT-N-16 below.

ID retained for traceability stability; do not regenerate the spec body until a full /test-spec rerun.

---

FT-P-10: Encryption Round-Trip Verification — OBSOLETE (cycle 2, 2026-05-14)

Same removal as FT-P-09. Additionally Security.DecryptTo and the e2e test Encryption_round_trip_decrypt_matches_original_bytes (in ResourceTests.cs) are gone. ID retained for traceability stability.

---

FT-P-11: Change User Role

Summary: ApiAdmin changes a user's role. Traces to: AC-9 Category: User Management

Preconditions:

• Target user exists, caller is ApiAdmin

Input data: {"email":"testuser@test.com","role":"Admin"}

Steps:

Step	Consumer Action	Expected System Response
1	PUT /users/role with ApiAdmin JWT	HTTP 200

Expected outcome: HTTP 200, role updated Max execution time: 5s

---

FT-P-12: Disable User Account

Summary: ApiAdmin disables a user account. Traces to: AC-9 Category: User Management

Preconditions:

• Target user exists, caller is ApiAdmin

Input data: {"email":"testuser@test.com","isEnabled":false}

Steps:

Step	Consumer Action	Expected System Response
1	PUT /users/enable with ApiAdmin JWT	HTTP 200

Expected outcome: HTTP 200, account disabled Max execution time: 5s

---

FT-P-13: Delete User

Summary: ApiAdmin deletes a user account. Traces to: AC-9 Category: User Management

Preconditions:

• Target user exists, caller is ApiAdmin

Input data: DELETE /users?email=testuser@test.com

Steps:

Step	Consumer Action	Expected System Response
1	DELETE /users?email=testuser@test.com with ApiAdmin JWT	HTTP 200

Expected outcome: HTTP 200, user deleted Max execution time: 5s

---

Negative Scenarios

FT-N-01: Login with Unknown Email

Summary: Login attempt with non-existent email returns appropriate error. Traces to: AC-2 Category: Authentication

Preconditions:

• Email does not exist in database

Input data: {"email":"nonexistent@test.com","password":"anypass1"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /login with unknown email	HTTP 409, ExceptionEnum code 10 (NoEmailFound)

Expected outcome: HTTP 409 with error code 10 Max execution time: 5s

---

FT-N-02: Login with Wrong Password

Summary: Login attempt with correct email but wrong password returns error. Traces to: AC-3 Category: Authentication

Preconditions:

• User exists in database

Input data: {"email":"admin@azaion.com","password":"wrongpassword123"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /login with wrong password	HTTP 409, ExceptionEnum code 30 (WrongPassword)

Expected outcome: HTTP 409 with error code 30 Max execution time: 5s

---

FT-N-03: Register with Short Email

Summary: Registration with email shorter than 8 characters is rejected. Traces to: AC-5 Category: User Management

Preconditions:

• Caller authenticated as ApiAdmin

Input data: {"email":"short","password":"validpwd1","role":"Operator"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /users with short email	HTTP 400, validation error

Expected outcome: HTTP 400 with email length validation error Max execution time: 5s

---

FT-N-04: Register with Invalid Email Format

Summary: Registration with invalid email format (>= 8 chars but not email) is rejected. Traces to: AC-6 Category: User Management

Preconditions:

• Caller authenticated as ApiAdmin

Input data: {"email":"notanemail","password":"validpwd1","role":"Operator"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /users with invalid email format	HTTP 400, validation error

Expected outcome: HTTP 400 with email format validation error Max execution time: 5s

---

FT-N-05: Upload Empty File

Summary: Upload request with no file attached returns error. Traces to: AC-16 Category: Resource Distribution

Preconditions:

• Caller authenticated

Input data: POST /resources/testfolder with no file

Steps:

Step	Consumer Action	Expected System Response
1	POST /resources/testfolder with empty request	HTTP 409, ExceptionEnum code 70 (NoFileProvided)

Expected outcome: HTTP 409 with error code 70 Max execution time: 5s

---

FT-N-06: Hardware Mismatch

Summary: Hardware check with different fingerprint after binding returns error. Traces to: AC-12 Category: Hardware Binding

Preconditions:

• User has hardware already bound to a different fingerprint

Input data: {"hardware":"different-hardware-xyz"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /resources/check with different hardware	HTTP 409, ExceptionEnum code 40 (HardwareIdMismatch)

Expected outcome: HTTP 409 with error code 40 Max execution time: 5s

---

FT-N-07: Register Duplicate Email

Summary: Registration with already-existing email returns error. Traces to: AC-8 Category: User Management

Preconditions:

• User with target email already exists

Input data: {"email":"admin@azaion.com","password":"validpwd1","role":"Operator"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /users with existing email	HTTP 409, ExceptionEnum code 20 (EmailExists)

Expected outcome: HTTP 409 with error code 20 Max execution time: 5s

---

FT-N-08: Register with Short Password

Summary: Registration with password shorter than 8 characters is rejected. Traces to: AC-7 Category: User Management

Preconditions:

• Caller authenticated as ApiAdmin

Input data: {"email":"newuser@test.com","password":"short","role":"Operator"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /users with short password	HTTP 400, validation error

Expected outcome: HTTP 400 with password length validation error Max execution time: 5s

---

Cycle 1 Additions (2026-05-13)

The scenarios below were appended during the existing-code cycle 1 Test-Spec Sync (autodev Step 12) for tasks AZ-513, AZ-196, AZ-183, AZ-197. Numbering continues from the legacy IDs above; existing IDs are preserved.

Cycle 1 Obsoletion Note

The following legacy entries describe behaviour removed by AZ-197 (admin-side hardware-binding cleanup). Their bodies are intentionally left intact to preserve traceability IDs per the cycle-update rule "preserve existing traceability IDs"; they should be treated as obsolete and superseded by FT-N-15 below:

• FT-P-04 (First Hardware Check Stores Fingerprint) — superseded; the POST /resources/check endpoint and the hardware-store side-effect were removed.
• FT-P-05 (Subsequent Hardware Check Matches) — superseded; same endpoint removed.
• FT-N-06 (Hardware Mismatch) — superseded; the HardwareIdMismatch / error code 40 path no longer exists in ExceptionEnum.
• FT-P-09 / FT-P-10 — fully obsolete after the cycle-2 cleanup; the endpoint, support code, and corresponding e2e tests are gone (see the FT-P-09 / FT-P-10 stubs above and FT-N-16 below).

See _docs/03_implementation/batch_06_report.md for the full AZ-197 implementation rationale and the wire-compat policy decision (drop entirely).

---

Cycle-2 Cleanup (2026-05-14) — Obsolete Resource Endpoints Removed

FT-N-16: Removed Resource Endpoints Return 404

Summary: After the cycle-2 cleanup, the three obsolete resource endpoints are no longer routed and return 404. Traces to: Cycle-2 AC-1, Cycle-2 AC-2, Cycle-2 AC-3 Category: Negative — Removed Endpoints

Preconditions:

• Caller authenticated as any user (404 must precede any auth check, since the route is gone)

Steps:

Step	Consumer Action	Expected System Response
1	POST /resources/get (with or without body)	HTTP 404
2	POST /resources/get/somefolder	HTTP 404
3	GET /resources/get-installer	HTTP 404
4	GET /resources/get-installer/stage	HTTP 404

Expected outcome: each request returns HTTP 404 (not 401, not 405); no Security.GetApiEncryptionKey / EncryptTo invocation observable in logs.

Notes: this is a parallel to FT-N-15 (which covers the AZ-197 endpoint removals). Together they enumerate every route that has been retired in cycles 1 and 2.

---

Detection Classes CRUD (AZ-513)

FT-P-14: POST /classes Creates Detection Class

Summary: ApiAdmin creates a new detection class and the response includes the assigned id. Traces to: AZ-513 AC-1 Category: Detection Classes CRUD

Preconditions:

• Caller authenticated as ApiAdmin
• detection_classes table exists

Input data: {"name":"Tank","shortName":"T","color":"#FF0000","maxSizeM":5.0}

Steps:

Step	Consumer Action	Expected System Response
1	POST /classes with valid body and ApiAdmin JWT	HTTP 200/201 with body containing assigned id and the submitted fields

Expected outcome: HTTP 200 or 201, response body has integer id and matches input fields Max execution time: 5s

---

FT-P-15: PATCH /classes/{id} Full Body Update

Summary: Updating a detection class with a full body replaces the changed fields. Traces to: AZ-513 AC-3 Category: Detection Classes CRUD

Preconditions:

• A detection class with id 7 exists with name: "Tank"

Input data: {"name":"Heavy Tank","shortName":"T","color":"#FF0000","maxSizeM":5.0} to PATCH /classes/7

Steps:

Step	Consumer Action	Expected System Response
1	PATCH /classes/7 with full body and ApiAdmin JWT	HTTP 200, response body shows name: "Heavy Tank"

Expected outcome: HTTP 200, updated entity reflects the changed field Max execution time: 5s

---

FT-P-16: PATCH /classes/{id} Partial Body Update

Summary: PATCH with only the changed field updates that field and leaves others intact. Traces to: AZ-513 AC-4 Category: Detection Classes CRUD

Preconditions:

• A detection class with id 7 exists with name: "Tank", color: "#FF0000", maxSizeM: 5.0

Input data: {"color":"#00FF00"} to PATCH /classes/7

Steps:

Step	Consumer Action	Expected System Response
1	PATCH /classes/7 with partial body and ApiAdmin JWT	HTTP 200, response body shows color: "#00FF00"; other fields unchanged

Expected outcome: HTTP 200, partial-merge semantics confirmed Max execution time: 5s

---

FT-P-17: DELETE /classes/{id} Removes Class

Summary: ApiAdmin deletes a detection class and it disappears from the DB. Traces to: AZ-513 AC-7 Category: Detection Classes CRUD

Preconditions:

• A detection class with id 7 exists

Input data: DELETE /classes/7

Steps:

Step	Consumer Action	Expected System Response
1	DELETE /classes/7 with ApiAdmin JWT	HTTP 200 or 204
2	GET the class list (or PATCH the same id)	id 7 no longer present

Expected outcome: HTTP 200/204; class removed from DB Max execution time: 5s

---

FT-N-09: POST /classes Without ApiAdmin JWT

Summary: POST /classes requires the same apiAdminPolicy as /users; non-admin / unauthenticated calls are rejected. Traces to: AZ-513 AC-2 Category: Detection Classes CRUD

Preconditions: None (negative path)

Input data: Valid body, but caller has no JWT or a non-ApiAdmin JWT

Steps:

Step	Consumer Action	Expected System Response
1	POST /classes without JWT	HTTP 401
2	POST /classes with non-ApiAdmin JWT	HTTP 403

Expected outcome: HTTP 401 (no JWT) or 403 (non-admin) Max execution time: 5s

---

FT-N-10: PATCH /classes/{id} Unknown id Returns 404

Summary: PATCH against a non-existent id returns 404. Traces to: AZ-513 AC-5 Category: Detection Classes CRUD

Preconditions: No detection class with id 9999

Input data: PATCH /classes/9999 with any valid body

Steps:

Step	Consumer Action	Expected System Response
1	PATCH /classes/9999 with ApiAdmin JWT	HTTP 404

Expected outcome: HTTP 404 Max execution time: 5s

---

FT-N-11: PATCH /classes/{id} Without ApiAdmin JWT

Summary: PATCH /classes/{id} requires apiAdminPolicy. Traces to: AZ-513 AC-6 Category: Detection Classes CRUD

Input data: Any valid body to PATCH /classes/{id}

Steps:

Step	Consumer Action	Expected System Response
1	PATCH /classes/{id} without JWT	HTTP 401
2	PATCH /classes/{id} with non-ApiAdmin JWT	HTTP 403

Expected outcome: HTTP 401 or 403 Max execution time: 5s

---

FT-N-12: DELETE /classes/{id} Unknown id Returns 404

Summary: DELETE against a non-existent id returns 404 (matching /users semantics — non-idempotent). Traces to: AZ-513 AC-8 Category: Detection Classes CRUD

Preconditions: No detection class with id 9999

Input data: DELETE /classes/9999

Steps:

Step	Consumer Action	Expected System Response
1	DELETE /classes/9999 with ApiAdmin JWT	HTTP 404

Expected outcome: HTTP 404 Max execution time: 5s

---

FT-N-13: DELETE /classes/{id} Without ApiAdmin JWT

Summary: DELETE /classes/{id} requires apiAdminPolicy. Traces to: AZ-513 AC-9 Category: Detection Classes CRUD

Input data: DELETE /classes/{id}

Steps:

Step	Consumer Action	Expected System Response
1	DELETE /classes/{id} without JWT	HTTP 401
2	DELETE /classes/{id} with non-ApiAdmin JWT	HTTP 403

Expected outcome: HTTP 401 or 403 Max execution time: 5s

---

Device Auto-Registration (AZ-196)

FT-P-18: POST /devices Returns Serial / Email / Password

Summary: First call to POST /devices returns the next serial in the azj-NNNN sequence with a generated email and 32-char hex password. Traces to: AZ-196 AC-1 Category: Device Provisioning

Preconditions:

• Caller authenticated as ApiAdmin
• No (or known-prior) CompanionPC users in DB

Input data: POST /devices with no body, ApiAdmin JWT

Steps:

Step	Consumer Action	Expected System Response
1	POST /devices with ApiAdmin JWT	HTTP 200 with serial matching ^azj-\d{4}$, email = {serial}@azaion.com, password = 32 lowercase hex chars

Expected outcome: HTTP 200, all three fields shaped per spec Max execution time: 5s

---

FT-P-19: Sequential Device Serials

Summary: Repeated calls to POST /devices yield strictly increasing serial numbers. Traces to: AZ-196 AC-2 Category: Device Provisioning

Preconditions:

• Most recent CompanionPC user has a known serial azj-NNNN

Input data: POST /devices twice in succession

Steps:

Step	Consumer Action	Expected System Response
1	POST /devices → record serial S1	HTTP 200
2	POST /devices → record serial S2	HTTP 200
3	Parse the numeric suffix of both	numeric(S2) == numeric(S1) + 1

Expected outcome: HTTP 200, suffix increments by exactly 1 Max execution time: 5s

---

FT-P-20: Returned Device Credentials Can Login

Summary: The plaintext password returned by POST /devices succeeds against POST /login (and the persisted hash is therefore correct). Traces to: AZ-196 AC-3, AZ-196 AC-4 Category: Device Provisioning

Preconditions:

• Caller authenticated as ApiAdmin

Input data: Use the response from POST /devices as {Email, Password} to POST /login

Steps:

Step	Consumer Action	Expected System Response
1	POST /devices with ApiAdmin JWT	HTTP 200, {Serial, Email, Password} returned
2	POST /login with the returned Email and Password	HTTP 200 with non-empty JWT

Expected outcome: HTTP 200 on login; persisted user has Role=CompanionPC, IsEnabled=true (verified by AdminApi behaviour rather than direct DB inspection) Max execution time: 5s

---

FT-N-14: POST /devices Without ApiAdmin JWT

Summary: POST /devices requires apiAdminPolicy. Traces to: AZ-196 AC-5 Category: Device Provisioning

Input data: POST /devices

Steps:

Step	Consumer Action	Expected System Response
1	POST /devices without JWT	HTTP 401
2	POST /devices with non-ApiAdmin JWT	HTTP 403

Expected outcome: HTTP 401 or 403 Max execution time: 5s

---

Resources OTA Update Check (AZ-183) — REVERTED post-cycle-1

The OTA update check & publish feature shipped in cycle 1 was reverted later the same day after the security audit (finding F-1: /get-update disclosed plaintext per-resource encryption keys to any authenticated caller). The OTA delivery model itself was deemed obsolete in the target architecture.

The scenarios FT-P-21, FT-P-22, FT-P-23 are retained here as ID placeholders so previously-cited references resolve. Their bodies are intentionally collapsed because the underlying endpoints, service, entity, table, and the e2e test class ResourceUpdateTests.cs were all removed. See _docs/02_document/system-flows.md (Flow F10) and _docs/05_security/security_report.md (finding F-1) for context.

Removed Test ID	Was tracing	Disposition
FT-P-21	AZ-183 AC-2	Removed — endpoint and test deleted
FT-P-22	AZ-183 AC-3	Removed — endpoint and test deleted
FT-P-23	AZ-183 AC-5	Removed — endpoint and test deleted

---

Hardware-Binding Removal (AZ-197)

FT-N-15: Hardware Endpoints Removed

Summary: The legacy PUT /users/hardware/set endpoint and the POST /resources/check endpoint have been removed and now return 404. Traces to: AZ-197 AC-2 Category: Authorization & Routing

Preconditions:

• Updated admin API build (post-AZ-197)

Input data: PUT /users/hardware/set and POST /resources/check

Steps:

Step	Consumer Action	Expected System Response
1	PUT /users/hardware/set with ApiAdmin JWT	HTTP 404
2	POST /resources/check with ApiAdmin JWT	HTTP 404

Expected outcome: HTTP 404 on both routes Max execution time: 5s

Note: AZ-197 AC-1 (resource download works without Hardware) is implicitly covered by the existing FT-P-09 / FT-P-10 scenarios once their request bodies are aligned with the new wire shape. AZ-197 AC-3..AC-8 are internal-signature / build-system invariants and are verified at build/CI time, not via a blackbox HTTP scenario.

---

Cycle 2 Additions (2026-05-14) — Auth Modernization (AZ-529 + AZ-530)

The scenarios below were appended during the existing-code cycle 2 Test-Spec Sync (autodev Step 12) for the eight tasks under AZ-529 (Auth Mechanism Modernization) and AZ-530 (CMMC Compliance Hardening): AZ-531 (refresh-token flow), AZ-532 (asymmetric signing + JWKS), AZ-533 (mission-token UAV), AZ-534 (TOTP 2FA), AZ-535 (logout + revocation), AZ-536 (Argon2id), AZ-537 (rate-limit + lockout), AZ-538 (CORS HTTPS-only + HSTS). Numbering continues from FT-P-23 / FT-N-16. Security-only ACs live in security-tests.md.

Argon2id Password Hashing (AZ-536)

FT-P-24: Legacy SHA-384 Password Still Validates

Summary: A user whose password_hash is in the pre-AZ-536 unsalted SHA-384 format can still log in with the correct password. Traces to: AZ-536 AC-2 Category: Authentication

Preconditions:

• Seed user legacy@azaion.com with password_hash set to Convert.ToBase64String(SHA384.HashData("LegacyPwd1!")) (the historical format)

Input data: {"email":"legacy@azaion.com","password":"LegacyPwd1!"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /login with the legacy user's credentials	HTTP 200, dual-token body (per AZ-531)

Expected outcome: HTTP 200, login succeeds against legacy hash format Max execution time: 5s (note: Argon2id verify cost is incurred only on the post-login re-hash)

---

FT-P-25: Successful Legacy Login Re-Hashes to Argon2id

Summary: After FT-P-24 succeeds, the user's password_hash is silently upgraded to Argon2id PHC format and the same plaintext continues to validate. Traces to: AZ-536 AC-3 Category: Authentication

Preconditions:

• FT-P-24 has just executed successfully for legacy@azaion.com

Input data: {"email":"legacy@azaion.com","password":"LegacyPwd1!"}

Steps:

Step	Consumer Action	Expected System Response
1	Read users.password_hash for legacy@azaion.com directly from DB	Value starts with $argon2id$v=19$m= and parses to m ≥ 65536, t ≥ 3, p ≥ 1
2	POST /login with the same plaintext password again	HTTP 200, dual-token body

Expected outcome: Hash format upgraded to Argon2id PHC; subsequent login still works Max execution time: 5s

---

FT-N-17: Wrong Password Fails for Both Hash Formats

Summary: Wrong password is rejected with the same error (WrongPassword) regardless of whether the stored hash is legacy SHA-384 or Argon2id. Traces to: AZ-536 AC-4 Category: Authentication

Preconditions:

• One user with legacy SHA-384 hash, one user with Argon2id hash already in DB

Input data: Wrong password against each user

Steps:

Step	Consumer Action	Expected System Response
1	POST /login (legacy user, wrong pwd)	HTTP 409, ExceptionEnum=WrongPassword (code 30)
2	POST /login (Argon2id user, wrong pwd)	HTTP 409, ExceptionEnum=WrongPassword (code 30)

Expected outcome: Same error code on both code paths; no information leak about hash format Max execution time: 5s per attempt (Argon2id cost incurred regardless of success/failure)

---

/login Rate Limit + Account Lockout (AZ-537)

FT-P-26: Successful Login Resets the Failed-Attempt Counter

Summary: After some wrong-password attempts (within budget), a successful login zeros failed_login_count and clears lockout_until. Traces to: AZ-537 AC-4 Category: Authentication

Preconditions:

• User alice@azaion.com exists with Argon2id-hashed password

Input data: 5 wrong-password attempts followed by 1 correct attempt

Steps:

Step	Consumer Action	Expected System Response
1	POST /login with wrong pwd × 5 (within rate-limit budget)	HTTP 409 each (WrongPassword)
2	Read users.failed_login_count for alice	Value = 5
3	POST /login with correct pwd	HTTP 200, dual-token body
4	Read users.failed_login_count and lockout_until for alice	failed_login_count = 0, lockout_until IS NULL

Expected outcome: Counter reset on success Max execution time: 30s (5× Argon2id verifies)

---

FT-P-27: Lockout Auto-Expires After Configured Duration

Summary: A locked account becomes loginable again automatically once lockout_until < now(). Traces to: AZ-537 AC-5 Category: Authentication

Preconditions:

• Auth:Lockout:DurationMinutes set to a small value (e.g. 1 minute) in the test env so the test does not have to wait 15 min
• User bob@azaion.com exists with Argon2id hash

Input data: 10 wrong attempts to trigger lockout, then a correct attempt after the duration window

Steps:

Step	Consumer Action	Expected System Response
1	POST /login with wrong pwd × 10	first 9 → 409 WrongPassword; the 10th → 423 Locked OR 409 followed by lockout flag
2	POST /login with correct pwd immediately	HTTP 423 Locked (account is locked)
3	Wait Auth:Lockout:DurationMinutes + 1s	—
4	POST /login with correct pwd	HTTP 200, dual-token body

Expected outcome: 423 → 200 transition once the lockout window expires Max execution time: 90s (depends on configured lockout duration in test env)

---

CORS HTTPS-Only + HSTS (AZ-538)

FT-P-28: HTTPS Origin Preflight Succeeds

Summary: The CORS allow-list still admits the canonical https://admin.azaion.com origin and echoes the credentials flag. Traces to: AZ-538 AC-2 Category: Cross-Origin

Preconditions:

• Admin API running with AdminCorsPolicy configured (post-AZ-538)

Input data:

• Method: OPTIONS
• Path: /login
• Header: Origin: https://admin.azaion.com
• Header: Access-Control-Request-Method: POST

Steps:

Step	Consumer Action	Expected System Response
1	OPTIONS /login with the headers above	HTTP 204; Access-Control-Allow-Origin: https://admin.azaion.com; Access-Control-Allow-Credentials: true

Expected outcome: HTTPS origin preflight succeeds with credentials flag Max execution time: 5s

---

FT-P-29: Development Env — No HTTPS Redirect, No HSTS

Summary: When ASPNETCORE_ENVIRONMENT=Development, plain HTTP requests to localhost still serve 200 responses with no Strict-Transport-Security header. Traces to: AZ-538 AC-5 Category: Cross-Origin

Preconditions:

• Admin API running with ASPNETCORE_ENVIRONMENT=Development (the default test container env)

Input data: GET http://localhost:8080/health/live

Steps:

Step	Consumer Action	Expected System Response
1	GET http://localhost:8080/health/live	HTTP 200; no Strict-Transport-Security header; no 307 redirect

Expected outcome: Dev workflow preserved — no redirect, no HSTS Max execution time: 5s

---

Refresh-Token Flow (AZ-531)

FT-P-30: /login Returns Dual Tokens

Summary: Successful login returns both a short-lived access token (≈15 min) and an opaque refresh token; a sessions row is created. Traces to: AZ-531 AC-1 Category: Authentication

Preconditions:

• Seed user without MFA enabled

Input data: Valid email + password

Steps:

Step	Consumer Action	Expected System Response
1	POST /login	HTTP 200; body has access_token (JWT), access_exp ≈ now+15m ±60s, refresh_token (opaque ≥43 chars), refresh_exp
2	Decode access_token payload	Contains sub, iss, aud, exp, jti, sid claims
3	Query sessions table by user_id	Exactly one row with non-null refresh_hash, non-null family_id, revoked_at IS NULL

Expected outcome: Dual tokens issued, session row persisted, access token has short TTL Max execution time: 5s

---

FT-P-31: /token/refresh Rotates the Refresh Token

Summary: A valid refresh token is exchanged for a new access + new refresh; the previous refresh is invalidated; the session chain extends via parent_session_id. Traces to: AZ-531 AC-2 Category: Authentication

Preconditions:

• FT-P-30 just produced refresh token R1

Input data: {"refresh_token":"<R1>"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /token/refresh with R1	HTTP 200; body has new access_token, new refresh_token (R2 ≠ R1), new access_exp, new refresh_exp
2	POST /token/refresh with R1 again (same call)	HTTP 401 (R1 has been rotated; see AC-3 reuse-detection in NFT-SEC-08)
3	Inspect sessions table	Original row's refresh_hash rotated; new row has parent_session_id chained to the previous row

Expected outcome: Rotation succeeds; old refresh dies; chain is preserved Max execution time: 5s

---

FT-P-32: Refresh Sliding + Absolute Expiry

Summary: Refresh tokens slide on use up to the per-family absolute cap (12 h since the family's first issue); after the absolute cap, refresh fails. Traces to: AZ-531 AC-4 Category: Authentication

Preconditions:

• A sessions family with family_first_issued_at set to now() - 11h59m (verified via DB seed) and a current valid refresh token R-current

Input data: {"refresh_token":"<R-current>"}, called near and past the absolute cap

Steps:

Step	Consumer Action	Expected System Response
1	POST /token/refresh at family-age 11h59m	HTTP 200, rotation succeeds; sliding window extended
2	Seed another family with family_first_issued_at = now() - 12h01s	—
3	POST /token/refresh on that family	HTTP 401, body indicates absolute-expiry violation

Expected outcome: Sliding works inside 12 h; absolute cap rejects beyond Max execution time: 5s

---

Asymmetric Signing + JWKS (AZ-532)

FT-P-33: GET /.well-known/jwks.json Serves the Active Public Key

Summary: The JWKS endpoint is anonymous, cacheable, and returns a well-formed JWKS containing the active EC P-256 public key with kid. Traces to: AZ-532 AC-2 Category: Cryptography / Discovery

Preconditions:

• Admin running with an ES256 keypair loaded from secrets/jwt_signing_key.pem

Input data: None (anonymous GET)

Steps:

Step	Consumer Action	Expected System Response
1	GET /.well-known/jwks.json (no JWT)	HTTP 200; Content-Type: application/json; Cache-Control: public, max-age=3600
2	Parse body	{"keys":[{"kty":"EC","crv":"P-256","kid":<non-empty>,"x":<base64url>,"y":<base64url>,"alg":"ES256","use":"sig"}, …]}

Expected outcome: JWKS shape matches RFC 7517; cache headers present Max execution time: 5s

---

FT-P-34: Two-Key Overlap During Rotation

Summary: When two signing keys are configured (kid-A active + kid-B standby), JWKS exposes both; tokens signed with the active key continue to verify; switching the active flag to kid-B produces kid-B-stamped tokens that also verify. Traces to: AZ-532 AC-3 Category: Cryptography / Rotation

Preconditions:

• Two keys configured in secrets/: jwt_signing_key_a.pem (active), jwt_signing_key_b.pem (standby)

Input data: Sequenced login + rotation toggle

Steps:

Step	Consumer Action	Expected System Response
1	GET /.well-known/jwks.json	Both kid-A and kid-B appear in keys array
2	POST /login	Returned access token has kid: kid-A in header
3	Toggle active key → kid-B (test-only admin endpoint or env reload)	—
4	POST /login again	Returned access token has kid: kid-B in header
5	Use either token against any protected endpoint	HTTP 200 (both verify against their respective public keys in JWKS)

Expected outcome: Overlap window allows both keys; verifiers can keep working through rotation Max execution time: 10s

---

Mission-Token Issuance for UAV (AZ-533)

FT-P-35: POST /sessions/mission Issues a Long-Lived Mission Token

Summary: An authenticated pilot session can mint a mission-class access token with a duration ≈ planned_duration_h + 1h and no refresh token. Traces to: AZ-533 AC-1 Category: Mission Sessions

Preconditions:

• Pilot user with valid (post-AZ-531) access token; MFA already proven within the session (post-AZ-534)
• Aircraft user UAV-117 with Role=CompanionPC exists

Input data: {"mission_id":"M-2026-05-14-042","aircraft_id":"UAV-117","planned_duration_h":9,"requested_scope":["GPS"]}

Steps:

Step	Consumer Action	Expected System Response
1	POST /sessions/mission with the body above + pilot access token	HTTP 200; body has access_token, no refresh_token, exp ≈ now + 10h ±60s
2	Decode token payload	token_class = "mission"
3	Query sessions table	Row with class='mission', aircraft_id='UAV-117', revoked_at IS NULL

Expected outcome: Long-lived mission token issued; session persisted with class marker Max execution time: 5s

---

FT-P-36: Mission Token Carries Scope Claims

Summary: The mission token's payload exposes mission_id, aircraft_id, aud, permissions, sid, jti. Traces to: AZ-533 AC-3 Category: Mission Sessions

Preconditions:

• FT-P-35 just produced a mission token

Input data: The mission token from FT-P-35

Steps:

Step	Consumer Action	Expected System Response
1	Decode mission token payload	mission_id == "M-2026-05-14-042", aircraft_id == "UAV-117", aud == "satellite-provider", permissions contains "GPS", sid non-empty, jti non-empty

Expected outcome: All scope claims present and correctly populated Max execution time: 5s

---

FT-P-37: Mission Token Auto-Revoked on Aircraft Reconnect

Summary: When the aircraft user behind a mission session calls /login or /token/refresh again, every open mission session for that aircraft is marked revoked_reason='post_flight_reconnect' and the mission token stops working. Traces to: AZ-533 AC-4 Category: Mission Sessions

Preconditions:

• Open mission session for UAV-117 from FT-P-35 (token MT)

Input data: A /login from the UAV-117 companion PC user

Steps:

Step	Consumer Action	Expected System Response
1	POST /login as UAV-117 (CompanionPC creds)	HTTP 200, dual tokens (per AZ-531)
2	Query sessions row for the original mission MT	revoked_at set; revoked_reason = 'post_flight_reconnect'
3	Use MT against any protected endpoint	HTTP 401

Expected outcome: Reconnect implicitly revokes outstanding mission sessions for the same aircraft Max execution time: 10s

---

FT-N-18: POST /sessions/mission Requires Authentication

Summary: Without an Authorization header, mission-token issuance is rejected at the gateway. Traces to: AZ-533 AC-5 Category: Mission Sessions

Preconditions: None

Input data: Same body as FT-P-35, no Authorization header

Steps:

Step	Consumer Action	Expected System Response
1	POST /sessions/mission with no JWT	HTTP 401

Expected outcome: Unauthenticated mission requests are rejected Max execution time: 5s

---

FT-N-19: POST /sessions/mission Rejects Over-Cap Duration

Summary: A request for planned_duration_h > 12 is rejected with HTTP 400 and a descriptive error message. Traces to: AZ-533 AC-2 Category: Mission Sessions

Preconditions:

• Authenticated pilot session (with MFA amr=mfa)

Input data: {"mission_id":"M-2026-05-14-099","aircraft_id":"UAV-117","planned_duration_h":15,"requested_scope":["GPS"]}

Steps:

Step	Consumer Action	Expected System Response
1	POST /sessions/mission with the over-cap body	HTTP 400; response body contains "planned_duration_h must be ≤ 12"

Expected outcome: 400 with cap-violation message; no session row created Max execution time: 5s

---

TOTP-Based 2FA at Login (AZ-534)

FT-P-38: POST /users/me/mfa/enroll Returns Usable Secret + Recovery Codes

Summary: A user without MFA can begin enrollment and receives a 32-char base32 TOTP secret, an otpauth:// URL, a base64 PNG QR, and 10 recovery codes (≥12 chars each). Traces to: AZ-534 AC-1 Category: MFA Enrollment

Preconditions:

• Authenticated user mfauser@azaion.com, mfa_enabled = false

Input data: {"password":"<plaintext>"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /users/me/mfa/enroll with the body above	HTTP 200; body has secret (32-char base32), otpauth_url (matches ^otpauth://totp/), qr_png_base64 (non-empty), recovery_codes (length = 10, each ≥ 12 chars, base32)
2	Read users.mfa_enabled for the user	Value still false (only flips after confirm)

Expected outcome: Enrollment package returned; mfa_enabled not yet flipped Max execution time: 5s

---

FT-P-39: POST /users/me/mfa/confirm Activates MFA

Summary: Submitting a valid TOTP code from the just-issued secret completes enrollment and flips mfa_enabled = true. Traces to: AZ-534 AC-2 Category: MFA Enrollment

Preconditions:

• FT-P-38 just executed for the same user; the test holds the returned secret

Input data: {"code":"<TOTP code computed from secret at current time>"}

Steps:

Step	Consumer Action	Expected System Response
1	Compute current 6-digit TOTP from secret (RFC 6238, 30 s window)	6 digits
2	POST /users/me/mfa/confirm with the code	HTTP 200
3	Read users.mfa_enabled and users.mfa_enrolled_at	mfa_enabled = true, mfa_enrolled_at non-null

Expected outcome: MFA activated; subsequent /login goes through the two-step flow Max execution time: 5s

---

FT-P-40: Two-Step Login With TOTP

Summary: When a user has MFA enabled, /login returns an MFA-required envelope with a short-lived mfa_token; calling /login/mfa with the mfa_token + a valid TOTP code yields the real access + refresh; the access token's amr claim contains both pwd and mfa. Traces to: AZ-534 AC-3 Category: Authentication / MFA

Preconditions:

• User from FT-P-39 (MFA enabled)

Input data: Valid email + password, then mfa_token + TOTP code

Steps:

Step	Consumer Action	Expected System Response
1	POST /login with email + password	HTTP 200; body = { "mfa_required": true, "mfa_token": "<short-lived JWT>", "expires_in": 300 }; no access/refresh present
2	POST /login/mfa with { "mfa_token": "<from step 1>", "code": "<TOTP>" }	HTTP 200; body has access + refresh tokens
3	Decode access token	amr claim = ["pwd","mfa"]

Expected outcome: Two-step flow completes; access token's amr reflects both factors Max execution time: 10s

---

FT-P-41: Recovery Code Substitutes for TOTP and Burns On Use

Summary: A recovery code may be used in place of a TOTP code at /login/mfa. The same code on a subsequent attempt fails (single-use). The successful access token's amr claim records recovery. Traces to: AZ-534 AC-4 Category: Authentication / MFA

Preconditions:

• User from FT-P-39; the test holds the recovery_codes array from FT-P-38

Input data: First recovery code, then re-use of the same code

Steps:

Step	Consumer Action	Expected System Response
1	POST /login → get mfa_token	HTTP 200, MFA-required envelope
2	POST /login/mfa with { "mfa_token", "code": "<recovery_codes[0]>" }	HTTP 200, access + refresh issued; amr = ["pwd","mfa","recovery"]
3	POST /login → get a new mfa_token	HTTP 200, MFA-required envelope
4	POST /login/mfa with the SAME recovery code	HTTP 401 (recovery code burned)

Expected outcome: Recovery code works once, then is rejected Max execution time: 10s

---

FT-P-42: POST /users/me/mfa/disable Removes MFA

Summary: Submitting password + a valid TOTP code disables MFA; subsequent /login returns access + refresh directly without the two-step flow. Traces to: AZ-534 AC-5 Category: MFA Enrollment

Preconditions:

• User from FT-P-39

Input data: {"password":"<plaintext>","code":"<TOTP>"}

Steps:

Step	Consumer Action	Expected System Response
1	POST /users/me/mfa/disable	HTTP 200
2	Read users.mfa_enabled	false
3	POST /login with email + password	HTTP 200; body has access + refresh directly (no mfa_required)

Expected outcome: MFA disabled, single-step login restored Max execution time: 5s

---

Logout + Revocation Surface (AZ-535)

FT-P-43: POST /logout Revokes the Current Session

Summary: A POST /logout with a valid access token marks the session row revoked and disables the paired refresh token. Traces to: AZ-535 AC-1 Category: Session Lifecycle

Preconditions:

• Active session from a prior /login (access token A, refresh token R)

Input data: Authorization header Bearer <A>, empty body

Steps:

Step	Consumer Action	Expected System Response
1	POST /logout with bearer A	HTTP 200
2	Query the session row	revoked_at set; revoked_reason = 'user_logout'
3	POST /token/refresh with R	HTTP 401

Expected outcome: Session revoked, refresh dies immediately Max execution time: 5s

---

FT-P-44: POST /logout/all Revokes Every Session for the User

Summary: A user with multiple active sessions can sign out of all of them in one call. Traces to: AZ-535 AC-2 Category: Session Lifecycle

Preconditions:

• User with three active sessions S1/S2/S3 (each from a separate /login)

Input data: Authorization header Bearer <A from S1>, empty body

Steps:

Step	Consumer Action	Expected System Response
1	POST /logout/all from S1	HTTP 200
2	Query sessions for the user	All three rows have revoked_at set
3	POST /token/refresh with the refresh tokens of S1/S2/S3	All three return HTTP 401

Expected outcome: Every session for the user is revoked Max execution time: 10s

---

FT-P-45: POST /sessions/{sid}/revoke Lets Admin Kill Any Session

Summary: An Admin-role JWT can revoke any other user's session by id; the revoked row records the admin's user id. Traces to: AZ-535 AC-3 Category: Admin Session Management

Preconditions:

• Admin user with valid (post-AZ-531) access token
• Target user with active session SID-X

Input data: Authorization header Bearer <admin access>, path /sessions/<SID-X>/revoke

Steps:

Step	Consumer Action	Expected System Response
1	POST /sessions/SID-X/revoke as admin	HTTP 200
2	Query the SID-X row	revoked_at set; revoked_by_user_id = admin's user id
3	POST /token/refresh with SID-X's refresh	HTTP 401

Expected outcome: Admin-driven revocation works and records actor Max execution time: 5s

---

FT-P-46: GET /sessions/revoked?since=… Returns Recent, Non-Expired Revocations

Summary: A verifier identity (Role=Service) polls the snapshot endpoint and gets the recently-revoked, still-valid sessions; expired entries are auto-pruned. Traces to: AZ-535 AC-4 Category: Verifier Snapshot

Preconditions:

• 5 sessions revoked in the last hour, 2 of which already have exp < now()
• Verifier identity (Service role) with valid bearer

Input data: Authorization header Bearer <verifier access>, query ?since=<unix-ts 1h ago>

Steps:

Step	Consumer Action	Expected System Response
1	GET /sessions/revoked?since= with verifier bearer	HTTP 200; Cache-Control: no-cache; body is JSON array of length 3
2	Inspect each entry	{ jti, sid, exp } shape; no expired entries present

Expected outcome: 3 non-expired revocations returned; expired ones pruned Max execution time: 5s

---

FT-P-47: POST /logout Is Idempotent

Summary: Logging out a session that is already revoked returns 200 with already_revoked: true and does not write to the DB. Traces to: AZ-535 AC-5 Category: Session Lifecycle

Preconditions:

• Already-revoked session from FT-P-43

Input data: Authorization header Bearer <still-valid-but-stale access>, empty body

Steps:

Step	Consumer Action	Expected System Response
1	POST /logout again	HTTP 200; body { "already_revoked": true }
2	Query the session row's updated_at (or equivalent audit column)	Unchanged from before step 1

Expected outcome: Idempotent — no second DB mutation Max execution time: 5s