Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permitting multiple JWT schemes #57

Open
joshkel opened this issue Nov 14, 2023 · 0 comments
Open

Permitting multiple JWT schemes #57

joshkel opened this issue Nov 14, 2023 · 0 comments
Labels
feature New functionality or improvement

Comments

@joshkel
Copy link

joshkel commented Nov 14, 2023

Runtime

Node.js

Runtime version

18.18.2

Module version

3.2.0

Used with

Hapi 21

Any other relevant information

No response

What problem are you trying to solve?

We would like to have a Hapi route that allows two different sets of JWT tokens (with different issuers, audiences, and schemes). I thought that I could configure a route strategies for this; however, @hapi/jwt's errors always include error messages, which causes Hapi to reject the request (see here) rather than continue to the next scheme.

Do you have a new or modified API suggestion to solve the problem?

If I understand correctly, @hapi/jwt currently validates the timestamp, then audience, then issuer, then other token values, then the signature:

It seems to me that this is out of order and that a better approach would be the following:

  1. If an issuer is configured, then check the issuer. If the issuer does not match, then the current @hapi/jwt scheme is not responsible for this JWT and fails with a no-message unauthorized result so that Hapi continues authentication with the next configured strategy.
  2. Validate the signature, to avoid leaking information about valid audiences/etc. if there's no valid signature.
  3. Validate the remaining payload.

If this is too big a change (e.g., due to backward compatibility concerns or processing costs of retrieving and validating signatures), then could the issuer check be moved first, and add some sort of ignoreUnknownIssuer option be added to allow a no-message unauthorized result if the issuer doesn't match?

@joshkel joshkel added the feature New functionality or improvement label Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality or improvement
Projects
None yet
Development

No branches or pull requests

1 participant