refactor(auth): share verification primitives between middleware and KAS

[jrschumacher]

Goal

Centralize authentication-verification primitives shared by platform middleware and KAS, so required re-verification uses one maintained implementation rather than duplicated security logic.

Do not confuse removing duplicate code with removing required verification. Whether a second check is necessary is a separate security decision from which implementation performs it.

Current evidence and important distinction

KAS is not simply verifying the access token again: it validates a signed request token (SRT) bound to the request and signed with the client's DPoP key. Its srtSignatureAlgorithms map explicitly says it mirrors the auth package's DPoP proof allowlist. KAS also performs its own signature selection/verification and temporal-claim validation with configured skew.

Sources: KAS SRT claim/signature handling and mirrored allowlist, auth algorithm policy, and IPC route reauthentication.

Access tokens, DPoP proofs and KAS SRTs have different issuers/keys, claims, bindings and purposes. Shared code must not collapse these into one permissive generic JWT verifier. This issue records maintenance duplication, not a demonstrated verification bypass.

Bounded approach

1. Inventory what is already shared and what is genuinely duplicated across access-token verification, DPoP proofs and KAS SRTs.
2. Extract the smallest dependency-safe shared primitives—for example, supported asymmetric algorithm policy, key/algorithm compatibility, signature verification and temporal-policy handling where semantics genuinely match.
3. Keep clearly named artifact-specific verification profiles/wrappers and their distinct required claims and request bindings. Avoid a collection of boolean switches that silently bypass checks.
4. Migrate middleware and KAS to those primitives with behavior-preserving tests. Leave API-specific error translation and audit context at the appropriate boundary.

A shared allowlist/helper can be the first independently reviewable slice. Do not turn this into a wholesale auth rewrite or make KAS depend on server bootstrap internals.

Acceptance tests

• Document the shared/different rules for access tokens, DPoP proofs and SRTs before extraction.
• Reject unsupported algorithms, none/symmetric confusion, incompatible keys, bad signatures, malformed tokens and invalid temporal claims consistently where policies match.
• Preserve each artifact's distinct issuer/audience, request, key/thumbprint, nonce/replay and other required bindings where applicable; explicitly mark non-applicable rules rather than applying all profiles interchangeably.
• Test accepted RSA/EC/PSS cases supported by the current policies and configured clock-skew boundaries.
• Prove KAS request-token verification still occurs when required and selected IPC reauthentication remains intact.
• Preserve current error classification, challenge metadata, audit attribution and supported compatibility/configuration behavior; do not log token material.
• Demonstrate both consumers use the shared implementation. Measure any performance effect separately; no speedup is assumed from deduplication.

Non-goals and rollout

No authorization-policy redesign, automatic privileged-service mode, global token-verification cache, removed second checks, weakened claims, new accepted algorithms, or IPC transport/default changes. Any discovered policy divergence needs an explicit security decision, not accidental normalization during refactoring.

Downstream adaptation	Existing feature gate	High complexity	High coupling
None expected for internal behavior-preserving extraction; review any public helper API	N/A for behavior-preserving reuse; changed verification policy needs separate rollout	Conditional: keep the first primitive small	Yes: middleware, KAS and cryptographic policy

Release classification

Parent: #3996. Class: post-v1. Score: 3/10 — correctness/reliability 1/3, compatibility 1/3, operability 1/2, explicit v1 dependency 0/2.

Reducing policy drift is valuable, but duplication alone is not a proven release blocker. Promote the work if evidence establishes a required v1 dependency or a concrete security/compatibility defect. This is separate from #3995's transport experiment and #4003's internal-call authority contract.