cloudflare/workers-oauth-provider

feat: support private_key_jwt for CIMD clients

Ouverte

#264 ouverte le 29 juil. 2026

Voir sur GitHubGuide contributeur
 (0 commentaire) (0 réaction) (1 personne assignée)TypeScript (121 forks)github user discovery
enhancementgood first issue

Métriques du dépôt

Stars
 (1 786 étoiles)
Métriques de merge PR
 (Merge moyen 3j 15h) (42 PRs mergées en 30 j)

Description

Summary

Support private_key_jwt client authentication for clients identified by a Client ID Metadata Document.

Current behavior

CIMD support accepts only token_endpoint_auth_method: "none". Documents that advertise both none and private_key_jwt can work because the provider selects none, but a client that requires private_key_jwt cannot complete authorization code exchange.

This is not a core MCP compliance blocker because the MCP specification makes private_key_jwt optional. It is useful for clients that want stronger authentication than an unauthenticated public client.

Acceptance criteria

  • Parse and validate the client's jwks or jwks_uri metadata according to the CIMD draft.
  • Authenticate token endpoint requests using private_key_jwt.
  • Validate assertion issuer, subject, audience, signature, expiration, and unique identifier/replay constraints.
  • Apply SSRF protections to remotely fetched JWKS documents.
  • Advertise private_key_jwt only when the complete token-endpoint path is supported.
  • Add positive and negative tests for key rotation, invalid audience, expiry, replay, unknown keys, malformed assertions, and SSRF-sensitive URLs.
  • Document how this interacts with the global_fetch_strictly_public compatibility flag.

References

Guide contributeur

Direction de recherche
Étudiez le projet CIMD et la RFC 7523 pour comprendre les exigences de private key jwt. Inspectez le flux d'authentification du point de terminaison de jeton existant dans le code pour identifier les points d'intégration. Recherchez des techniques de protection SSRF pour la récupération des documents JWKS.
Stack technique
typescript
Domaine
backendauthenticationsecurity
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
4
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
3-5 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GitTypeScriptOAuth 2.0JSON Web Tokens
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
30