Offer one authenticated AuthProxy-to-application request envelope

[woksin]

Problem

AuthProxy currently relies on network isolation for downstream identity provenance. Reverse-proxied requests and /.cratis/me use unsigned x-ms-client-principal* headers; invitation/link/sign-in back-channels use JSON and bearer material with no common authenticated request contract. Adding the same unsigned headers to a back-channel does not improve provenance when a caller capable of forging the body can forge the headers too.

Proposed capability

Provide one reusable opt-in, versioned authenticated request envelope for final YARP forwarding and every AuthProxy-owned back-channel. Bind:

• canonical provider key, issuer, and subject;
• downstream audience and tenant where applicable;
• short iat/nbf/exp and unique request identifier;
• final method, path, ordered query, and exact body digest;
• invitation/link transaction or token context for their completion profiles.

Support active/previous keys, bounded replay protection, case-insensitive collision removal, and fail-closed verification. The producer must be reusable outside a YARP transform because AuthProxy directly calls /.cratis/me and other back-channels.

Acceptance criteria

Mutate signature, key id, audience, provider, issuer, subject, tenant, method, path/query ordering, body, expiry, duplicate/case-varied headers, and replay across replicas. Prove final proxied requests and every AuthProxy back-channel use the same producer contract. A consumer constructs a principal only after successful verification.

Legacy unsigned mode remains the default. A coordinated AuthProxy/consumer adapter release is required, but the additive mode does not inherently require a major version.

[woksin]

Picking this up. Posting intent before writing code, since this repo moves fast and I do not want to collide with anything in flight.

What the code does today

SignInNotifier.Notify posts an anonymous JSON object to SignIn:NotifyUrl over a bare IHttpClientFactory client, with no signature, no proof of origin, and no binding to the request it describes. Anything that can reach that endpoint therefore chooses which user the application records as having signed in — including which subject, which providerKey, and which issuer.

Proposed shape

Bind six facts into one envelope over the notification: provenance (who signed), audience (which application), route (method + URI), body (a digest of the exact bytes posted), time, and replay (a random jti).

Rather than introduce a second signing stack, extract and reuse what this repo already has. Invites/InvitationAttestationIssuer already mints RS256 JWS through JsonWebTokenHandler with kid rotation, issuer/audience, iat/nbf/exp, and a random 256-bit jti — four of the six bindings exist and are already specced. The plan is to lift its private issuing path into something both call sites share, then add the two that are missing: htm and htu for the route, and a digest of the request body, under the RFC 9449 (DPoP) claim names so the scheme is a profile of an existing standard rather than a bespoke one.

The digest must be taken over await content.ReadAsByteArrayAsync() — the serialized bytes actually sent — not over the anonymous object, or the binding proves nothing about what crossed the wire.

Compatibility

Gated entirely on new configuration. Absent configuration keeps today's unsigned behavior, so this is additive (minor) and no existing deployment changes behavior on upgrade.

Scope

The SignInNotifier arm alone. The invite-exchange and credential-link callbacks post similar payloads, but folding them in would widen this well past one reviewable change; if this shape is accepted they are the obvious follow-ups.

Considered and rejected

• RFC 9421 (HTTP Message Signatures) — the better long-term fit conceptually, but it means a second signing stack with no Microsoft.IdentityModel support, so every part of it would be hand-rolled and hand-specced.
• A static shared-secret header — replayable, and binds none of the six facts.
• mTLS — authenticates the channel, not the assertion; a compromised intermediary still forges freely, and it pushes the whole problem into deployment.

One thing worth flagging for whoever owns the roadmap

AuthProxy exposes no JWKS endpoint, so a verifying application has to pin the public key by configuration. That is workable and matches how invitation attestation is consumed today, but it means key rotation is a coordinated config change on both sides rather than a fetch. Worth deciding separately whether AuthProxy should publish JWKS.

Objections welcome before I write anything — particularly on the claim names and on whether the shared issuer extraction should land as its own change first.

[woksin]

Implemented in #101, shipped in v2.18.0 (merge e28e8397).

The sign-in notification can now carry a signed envelope binding six facts: provenance (iss + kid), audience (aud), route (htm/htu), body (body_hash, over the exact bytes posted), time (iat/nbf/exp, lifetime clamped to 10–60s) and replay (jti, 32 CSPRNG bytes). Route and body use the RFC 9449 claim names, so this is a profile of an existing scheme rather than a private one. A purpose claim keeps a sign-in notification and an invitation attestation from being swapped for one another.

Rather than stand up a second signing stack, InvitationAttestationIssuer's private issuing path was lifted into a shared AttestationSigner that both call sites use — one implementation, one place to audit.

Enabled entirely by configuration. Absent SignIn:Attestation, the request leaves exactly as it always has — proven by a spec that builds a notifier through the released four-argument constructor over the same input and compares byte counts and JSON. When it is configured and an envelope cannot be issued, nothing is posted at all: a notification that cannot be authenticated is worth less than none.

Two things worth recording for whoever picks up the follow-ups.

AuthProxy still exposes no JWKS endpoint. A verifying application pins public keys by configuration and selects by kid, matching how invitation attestation is already consumed. That works, but it makes rotation a coordinated config change on both sides rather than a fetch. Worth deciding separately.

Only the SignInNotifier arm is covered. The invite-exchange and credential-link back-channels post similar payloads; the invite arm carries an attestation but binds neither route nor body. Both are now a single call on the shared signer. The YARP arm and the /.cratis/me call are also named in the original request and are untouched.

Independent code and security review is recorded on #101, including a wire contract that no spec could falsify — every published claim name and the cross-protocol separating value existed in one file and was only ever compared against itself, so renaming it left the entire suite green. That is fixed and pinned.