Export less opinionated jwt token validation function

[JonNode28]

The validateJwtAccessToken function assumes the access token will be supplied in the authentication header which, while a common standard, is not always the case. A lower level function that accepts the access token (and dpop) and does the validation without knowing where the values came from would accomodate other strategies such as secure cookies. Happy to do the work if accepted

[panva]

Hello @JonNode28

less opinionated jwt token validation

There's little opinion in the function, it does exactly what the standard says it should do, sans the documented things it doesn't validate that you're expected to validate after the function resolves.

A lower level function that accepts the access token (and dpop) and does the validation without knowing where the values came from would accomodate other strategies such as secure cookies. Happy to do the work if accepted

I am not sure I want to support an API that does off-spec behaviours, it is also not needed, you can instantiate a Request to pass to the function without the need for any lower level API to accomodate for off-standard means of token transfer that you mention.

// with dpop
new Request(new URL("https://rs.example.com/api/path"), {
  method: "GET",
  headers: new Headers({
    authorization: "dpop <JWT Access Token>",
    dpop: "<DPoP JWT Proof>",
  }),
});

// without dpop
new Request(new URL("https://rs.example.com/api/path"), {
  method: "GET",
  headers: new Headers({
    authorization: "bearer <JWT Access Token>",
  }),
});

[JonNode28]

I didn't realise the spec mandates the use of an authorization header to pass in the access token? My understanding is there are trade offs between using request headers and cookies. For example it is possible to set an authorization cookie as httpOnly which can mitigate some of the effects of a XSS attack

[panva]

There are no standardized mechanisms for sending oauth access tokens other than the ones defined in RFC6750. Out of the three defined one is no longer supported as per the OAuth 2.0 Security Best Current Practice document (passing via a query string parameter) and the one where application/x-www-form-urlencoded body parameter is used is not applicable to most APIs. That leaves only the use of the Authorization Request Header Field which consequently is what DPoP mandates as well.

I've updated the validateJwtAccessToken docs to mention 6750 and the only supported method of sending.