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.

[markbrockhoff]

Hi @panva, first of all thanks for maintaining this and all your other amazing auth related libraries. 💯

As far as I can tell RFC9068 is only a "proposed standard" and not a full internet standard yet.

Right now I'm trying to validate the access token for requests made to my resource server. The issue is that the type header of the access token issued by my IDP is just "JWT" and not "at+jwt" as enforced by: RFC9068

So I wanted to ask about your view and intention for the validateJwtAccessToken funktion. As RFC9068 is only a "proposed standard" and not yet an internet standard it's difficult for me to blame the IDP here (although I'd like them to fully implement it).
Do you think enforcing a proposed standard for everyone might be to strict and limit the compatibility with maybe not that up-to-date IDPs or would you say to just use jose directly in this case to do the validation, without being as strict on the type header?

I'd be really interested in your opinion on this one. :)

Btw: I think it would also be great to have an example on how to validate an access token using the validateJwtAccessToken function in the repo.

[panva]

As RFC9068 is only a "proposed standard" and not yet an internet standard it's difficult for me to blame the IDP here

OAuth 2.0 is also "only" in a Proposed Standard, much like almost every finished and final RFC in the OAuth WG.

I'm not going to entertain this line of thought. RFC9068 is the only actual JWT AT interoperable profile that's been a finished standard since 3 years ago. Going lean on the typ would only open the door for someone else saying their IdP doesn't include client_id, and then another which doesn't have a sub when the AT is a client credentials one. No.

Btw: I think it would also be great to have an example on how to validate an access token using the validateJwtAccessToken function in the repo.

The function signature is really simple, I don't see the need.

[markbrockhoff]

Thanks for the quick and comprehensive answer. I wasn't aware the RFC landscape within OAuth was like this and understand your argument. I will try to use this argument for my IDP in order to comply with the RFC. Until then guess I'll just use jose directly.