-
Notifications
You must be signed in to change notification settings - Fork 356
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
Compliance with published RFC7519 #11
Comments
This would be useful to me. |
Yeah, I created a new type |
…tructure (#15) This PR aims at implementing compliance to RFC7519, as documented in #11 without breaking the public API. It creates a new struct `RegisteredClaims` and deprecates (but not removes) the `StandardClaims`. It introduces a new type `NumericDate`, which represents a JSON numeric date value as specified in the RFC. This allows us to handle float as well as int-based time fields in `aud`, `exp` and `nbf`. Additionally, it introduces the type `StringArray`, which is basically a wrapper around `[]string` to deal with the oddities of the JWT `aud` field.
When the library was initially started, RFC7519 did not exist - only its drafts. This has lead to some shortcomings over the years where the implementation, especially of the claims, diverged from the now published RFC.
For example, the draft at the time of the writing of the claims struct actually stated that
iat
,exp
and so on must be anIntDate
, which did not include the possibility of non-integer date representations. It got then later changed to aNumericDate
format in draft version 26, which - as @dunglas correctly pointed out - included also float representations (also strings).The aim would be to be as backwards compatible as possible, e.g. with the introduction of a new struct as suggested by @mfridman, which I will name for the lack of a better name
jwt.RFC7159Claims
for now.This also was the original problem behind the audience mixup in #6
Points to consider (and possibly replaced with a new struct or function):
ExpiresAt
,IssuedAt
,NotBefore
injwt.StandardClaims
are int64 instead of a (to be defined)NumericDate
type. Probably solvable with a new structVerifyIssuedAt
,VerifyNotBefore
,VerifyIssuedAt
ofjwt.StandardClaims
only compare against an int64 instead of theNumericDate
. Also probably solvable with a new structVerifyIssuedAt
,VerifyNotBefore
,VerifyIssuedAt
ofjwt.MapClaims
only compare against an int64 instead of theNumericDate
. Trickier. I do not want to touchjwt.MapClaims
too much. Probably the introduction of a new set of functions can be made and the old ones set to deprecated.Audience
ofjwt.StandardClaims
should be a[]string
instead ofstring
. Could also be part of the new structAnything else that comes to mind?
At some point, it would also probably a good idea to check, whether RFC8725 is also properly reflected in the implementation.
Originally posted by @oxisto in #9 (comment)
The text was updated successfully, but these errors were encountered: