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

Split jwt_token_invalid error type: separate error type for semantic token errors #795

Open
johakoch opened this issue Jan 30, 2024 · 1 comment

Comments

@johakoch
Copy link
Collaborator

Currently, there are three specific jwt error types:

  • jwt_token_missing for a missing token,
  • jwt_token_expired for an expired token,
  • jwt_token_invalid for an invalid token (token syntactically not a JWT, or not sufficient, e.g. because required claims are missing or have unexpected values).

As the jwt_token_invalid currently covers both syntactic and semantic invalidity, it's impossible to do separate error handling for semantic errors (like missing claims or unexpected claim values) on the one hand, and syntactic errors (like broken tokens, invalid signature) on the other.

The new error type should cover the following cases:

  • missing claim (as per required_claims attribute)
  • unexpected claim values (as per claims attribute); this also applies to issuer and audience verification.
@johakoch
Copy link
Collaborator Author

Additionally, the jwt lib throws jwt.ErrTokenNotValidYet if a token is used before nbf. Currently we treat this as jwt_token_invalid, too. In terms of how a client should react in this case, it's only "try again later, with the same token".
However this may be a rare case...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant