Delegated API access with OAuth on-behalf-of

Chapter 5 of 6

Implement#

1. Record the approved applications, permissions, and claim checks#

Review these files with the identity, application, downstream API, and delivery owners:

• artifacts/control-definition.json
• artifacts/identity/app-registrations.json
• artifacts/governance/authorization-matrix.md
• artifacts/governance/token-claim-contract.json
• artifacts/governance/threat-model.md

The client receives only the middle-tier delegated scope. The middle tier receives only the downstream delegated read scope. The downstream API decides whether the preserved user can read the requested resource.

2. Bind the Key Vault certificate#

Register the public certificate on the middle-tier application through the approved identity lifecycle. Configure the hosting platform's Key Vault integration to expose the exportable private certificate as a protected PFX at the approved runtime path.

Do not use the configure scripts to upload private key material. Preflight compares the approved thumbprint with the Key Vault certificate in both phases.

Once the binding is active, run the post-binding phase on the middle-tier host, where the protected PFX is mounted. That phase requires the approved thumbprint on the middle-tier registration and the certificate file at the approved path:

.\scripts\preflight.ps1 -ArtifactRoot (Resolve-Path .\artifacts) -Phase post-binding

./scripts/preflight.sh --artifact-root "$(realpath ./artifacts)" --phase post-binding

3. Preview and apply the delegated permissions#

From the operator workstation, run preflight again. The read-only plan must show only:

• the client application's exact middle-tier delegated scope;
• the middle tier's exact downstream delegated scope; and
• the approved delegated consent grant.

Apply the plan:

.\scripts\configure.ps1 -ArtifactRoot (Resolve-Path .\artifacts) -Confirm

./scripts/configure.sh --artifact-root "$(realpath ./artifacts)" --confirm

Pause if either script finds an existing conflicting scope ID, audience, consent grant, or certificate thumbprint. Resolve the registration through the identity owner listed in the control definition rather than overwriting it.

4. Deploy the Python middle tier#

Use the implementation component under artifacts/runtime/. Copy settings.json into the approved deployment configuration, resolve its required values there, and set OBO_SETTINGS_PATH to that protected copy.

Deploy through the organization's normal application pipeline. The component:

• validates the inbound delegated token against the issuer, audience, client, scope, and claim rules in token-claim-contract.json;
• creates an MSAL confidential client from the mounted PFX;
• requests only the approved downstream scope;
• calls one fixed HTTPS endpoint; and
• returns correlation and authorization status without returning the downstream payload.

Do not run it as a public sample service. Apply the host's normal network, TLS, scaling, patching, and telemetry controls.

5. Prepare the delivery checks#

Use the approved client to obtain two short-lived middle-tier access tokens interactively:

• one for the permitted user; and
• one for a user who lacks access to the downstream protected resource.

Write each token to a separate protected temporary file outside the repository. Restrict file permissions to the operator. The verification scripts read the files without printing their contents and remove no user-owned file automatically.

6. Delivery-owner checkpoint#

Before the checks, the delivery owner reviews:

• the read-only preflight plan;
• the exact consent grant;
• the certificate thumbprint and protected runtime path;
• payload-free diagnostic settings; and
• the downstream rule that distinguishes the permitted and denied users.

Do not continue if the two users differ only in the client or middle-tier permission. The failure-path check must exercise downstream user authorization.