-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Description
Is your feature request related to a problem? Please describe.
Currently, there are two options to authenticate using a private key JWT client assertion: PrivateKeyJwtProvider which builds a default JWT on the fly, and StaticPrivateKeyJwtProvider where the client provides the JWT. I'm talking from the perspective of the provider of an MCP server: I want clients to be as easy to build for people using my server as possible.
My problem is the following: it creates an extra burden on clients to have to sign the key themselves, but there are cases where having additional claims in the client assertion helps scoping the Access Token with a finer granularity than what scopes allow, because the Authorization Service may include additional claims in the Access Token based on the custom claim provided by the client in its assertion JWT for the Resource Server to consider when receiving said Access Token.
In particular, clients have to manage the additional dependency (most likely jose) directly from their app rather than as a transitive dependency of the MCP client, and they have to manage the assertion JWT aud claim appropriately (so they essentially have to re-implement Authorization Service discovery).
Describe the solution you'd like
If the PrivateKeyJwtProvider constructor accepted an additional claims: Record<string, unknown> parameter, the PrivateKeyJwtProvider could build a client assertion JWT with additional custom claims. The internal createPrivateKeyJwtAuth function already supports receiving arbitrary claims for the signed JWT, so the change would be minimal and only at the API level.
Describe alternatives you've considered
N/A
Additional context
As mentioned, the change would be very minimal, so if the maintainers are ok with the proposed approach, I'm happy to open a PR implementing this feature request.