feat(auth): client conformance for Workload Identity Federation (SEP-1933)

[coding-bobo]

Motivation

As autonomous workloads increasingly interact with MCP servers, the existing authorization mechanisms - primarily designed around human-centric OAuth flows or statically registered client credentials - impose operational friction and do not align with how modern platforms provision identity. Workloads running under Kubernetes, SPIFFE/SPIRE, or cloud-native runtimes already receive short-lived, cryptographically verifiable JWTs that reflect their runtime identity. Requiring those workloads to additionally register as OAuth clients or manage long-lived secrets adds complexity and weakens security posture.

SEP-1933 addresses this by letting MCP directly leverage platform-provided credentials via the JWT Bearer grant (RFC 7523), eliminating a separate client identity lifecycle while preserving strong authentication guarantees. This PR adds client conformance coverage for that flow, so any MCP client that claims SEP-1933 support can be checked against the same behavioural contract regardless of the underlying workload identity platform.

Scope

Conformance tests are scoped to client behaviour. From the client's perspective, it receives a pre-issued JWT assertion (via scenario context) and must present it correctly at the token endpoint. OIDC discovery, signing-key resolution, issuer-allowlist policy, and jti replay detection are authorization-server concerns and are deliberately deferred to AS conformance work - they don't exercise any new client code path.

What's included

Signing helper

• helpers/createWorkloadJwt.ts: generateWorkloadKeypair(alg?) and createWorkloadJwt(opts), plus JWT_BEARER_GRANT_TYPE and DEFAULT_WORKLOAD_JWT_ALG constants. Keypair generation is intentionally separated from signing so the scenario can sign with a key the AS does not trust without API gymnastics. expiresIn accepts either a duration string or an absolute epoch number, so already-expired assertions can be constructed deterministically for negative tests.
• helpers/createWorkloadJwt.test.ts: 13 unit tests (round-trip sign+verify, default lifetime, expired-token construction via numeric epoch, unique jti, array audience preservation per RFC 7519 §4.1.3, reserved-claim protection, caller-supplied jti/notBefore, algorithm override).
• cross-app-access.ts: two bare URN literals replaced with JWT_BEARER_GRANT_TYPE. No behaviour change.

API shape mirrors existing patterns in client-credentials.ts (keypair + PEM export) and cross-app-access.ts (SignJWT chain).

Scenario and clients

• src/scenarios/client/auth/wif-jwt-bearer.ts: generates an ES256 keypair per start(), pre-signs three JWT variants (valid_jwt, wrong_audience_jwt, expired_jwt) with neutral fixture values, passes them via context, and configures the conformance AS with grant_types: [jwt-bearer] and token_endpoint_auth_method: none. DCR is disabled and the client is pre-seeded with WIF_CLIENT_ID, matching the SEP-1933 model where trust is established at the issuer level rather than per-client.
• src/scenarios/client/auth/spec-references.ts: RFC_7523_JWT_BEARER and SEP_1933_WIF references.
• src/seps/sep-1933.yaml: requirement traceability.
• src/schemas/context.ts: auth/wif-jwt-bearer context schema.
• examples/clients/typescript/everything-client.ts: WifJwtBearerProvider, runWifJwtBearer, and six broken-client runners.
• examples/clients/typescript/auth-test-wif-*.ts: CLI entrypoints for each broken variant.
• src/scenarios/client/auth/index.ts: scenario registration in draftScenariosList.
• src/scenarios/client/auth/index.test.ts: happy-path via draft loop + 6 negative tests.

Checks implemented (9)

Check ID	What it verifies	Severity
wif-grant-type	Client sends grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer	FAILURE
wif-assertion-missing	Client includes the assertion parameter	FAILURE
wif-assertion-verified	JWT signature, audience, and expiry are valid	FAILURE
wif-assertion-expired	Client surfaces invalid_grant for an expired assertion	FAILURE
wif-assertion-audience	Client surfaces invalid_grant for a wrong-audience assertion	FAILURE
wif-assertion-malformed	Client surfaces invalid_grant for a bad-signature assertion	FAILURE
wif-no-retry	Client does not retry after a JWT-bearer failure	WARNING
wif-assertion-scope-rejected	Client surfaces invalid_scope and does not retry	WARNING
wif-grant-fallback	Client does not fall back to authorization_code after unauthorized_client	WARNING

wif-no-retry, wif-grant-fallback, and wif-assertion-scope-rejected are WARNING because RFC 7523 is silent on client retry and grant-type switching behaviour; they will be upgraded to FAILURE once SEP-1933 lands normative spec text.

Three requirements are explicitly deferred in src/seps/sep-1933.yaml (iss, sub, jti); all are AS policy decisions. The scenario does not expose iss or sub in context because the client presents a pre-signed token and has no mechanism to vary those claims.

Coverage vs. issue #223

Issue #223 lists seven negative checks. This PR covers all seven, plus additional client-observable checks:

• Directly from the issue: wif-assertion-expired (expired exp), wif-assertion-audience (wrong aud), wif-assertion-missing (missing assertion), wif-assertion-scope-rejected (invalid_scope), wif-grant-fallback (unauthorized_client without grant-type fallback).
• Added beyond the issue: wif-grant-type, wif-assertion-malformed, wif-no-retry, wif-assertion-verified.

The remaining three issue checks (invalid_grant/unauthorised sub, invalid_grant/replayed jti, issuer allowlist) exercise AS policy rather than client code paths and are deferred to AS conformance work.

Testing

• npx vitest run src/scenarios/client/auth/helpers/createWorkloadJwt.test.ts - 13 tests pass
• npx vitest run src/scenarios/client/auth/index.test.ts - 49 tests pass (6 WIF negative tests)
• npx vitest run - full suite passes (194 tests, 16 files, no regressions)
• npm run check - typecheck and lint clean

Closes / relates

• Closes modelcontextprotocol/conformance#223
• Implements client-side reference test coverage for modelcontextprotocol/modelcontextprotocol#1933