Chapter 6 of 6
Confirm the result#
Run both checks:
PowerShell
.\scripts\verify.ps1 `
-MiddleTierEndpoint "https://__APPROVED_HOST__/delegated-resource" `
-PermittedTokenFile $permittedTokenFile `
-DeniedTokenFile $deniedTokenFile
Bash
./scripts/verify.sh \
--middle-tier-endpoint "https://__APPROVED_HOST__/delegated-resource" \
--permitted-token-file "$permitted_token_file" \
--denied-token-file "$denied_token_file"
For the intended-path check, the permitted user's call returns 2xx, a correlation ID, and the downstream-authorized decision header. The downstream API authorizes the preserved user and the middle tier logs metadata only.
For the failure-path check, the denied user's call returns 401 or 403 with the downstream-denied decision header. This prevents an inbound-token or exchange failure from passing as a downstream authorization test. No protected resource is returned, no application-only retry occurs, and the failure remains correlated without recording either token or payload.
At the delivery-owner checkpoint, the owner observes both status codes and confirms that the downstream API made the user-specific decision. The client prompt and middle-tier instructions do not make that decision.
After implementation#
Keep:
- the approved app-registration and consent definitions;
- the authorization matrix and token claim rules;
- the certificate reference and thumbprint;
- the Python middle-tier component and pinned dependencies;
- the threat model; and
- the paired operational scripts.
The identity owner owns delegated permissions and consent. The application owner owns inbound validation and certificate use. The downstream API owner owns resource authorization. Operations owns payload-free diagnostics and certificate-expiry alerting.
To remove the module-owned permission and consent entries, the identity owner checks the optional-module-obo-delegated-access marker and approved scope IDs, then removes only the module-owned delegated grants through the approved Entra change path. Do not delete application registrations, service principals, the Key Vault certificate, the downstream API, or unrelated permissions. Retire the certificate through the normal identity lifecycle only after no other approved workload uses it.