feat(auth): JWT-bearer helper for WIF client conformance (SEP-1933)#268
Draft
coding-bobo wants to merge 1 commit into
Draft
feat(auth): JWT-bearer helper for WIF client conformance (SEP-1933)#268coding-bobo wants to merge 1 commit into
coding-bobo wants to merge 1 commit into
Conversation
Adds createWorkloadJwt and generateWorkloadKeypair to provide reusable, tested JWT signing infrastructure for the upcoming wif-jwt-bearer scenario (PR modelcontextprotocol#2). Also extracts JWT_BEARER_GRANT_TYPE constant and migrates cross-app-access.ts to use it. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This was referenced May 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Relates to #223
Problem
Issue #223 adds client conformance tests for Workload Identity Federation (SEP-1933, RFC 7523). The scenario needs a reliable way to generate signed JWT assertions server-side and hand them to the client under test. Without a shared helper, each negative test case would re-implement JWT signing independently.
Design
This is PR 1 of 2. It adds the signing infrastructure only — no scenario is registered and there is no change to runtime behaviour. PR 2 will add the
wif-jwt-bearerscenario,everything-clienthandler, broken example clients, negative vitest cases, registration, and expected-failures baselines.The helper API mirrors existing patterns in
client-credentials.ts(keypair generation, PEM export) andcross-app-access.ts(SignJWT chain). Keypair generation is separate from signing so PR 2's negative tests can sign with a key the AS does not trust without API gymnastics.Changes
helpers/createWorkloadJwt.ts—generateWorkloadKeypair(alg?)andcreateWorkloadJwt(opts)plusJWT_BEARER_GRANT_TYPEandDEFAULT_WORKLOAD_JWT_ALGconstants.expiresInaccepts a jose duration string or an absolute epoch number — the number form lets PR 2 construct already-expired assertions for negative tests.helpers/createWorkloadJwt.test.ts— 13 unit tests (first isolated unit tests inhelpers/): round-trip sign+verify, default 5-minute lifetime, expired-token construction via numeric epoch, uniquejti, array audience preservation (RFC 7519 §4.1.3),additionalClaimsnot overriding reserved claims, caller-suppliedjti,notBefore, and algorithm override.cross-app-access.ts— two bare URN string literals replaced withJWT_BEARER_GRANT_TYPE. No behaviour change.Testing
npx vitest run src/scenarios/client/auth/helpers/createWorkloadJwt.test.ts— 13 tests passnpx vitest run— full suite passes (131 tests, 10 files, no regressions)npm run check— typecheck and lint clean