-
Notifications
You must be signed in to change notification settings - Fork 419
Description
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 an IntDate
, which did not include the possibility of non-integer date representations. It got then later changed to a NumericDate
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):
- The fields
ExpiresAt
,IssuedAt
,NotBefore
injwt.StandardClaims
are int64 instead of a (to be defined)NumericDate
type. Probably solvable with a new struct - The functions
VerifyIssuedAt
,VerifyNotBefore
,VerifyIssuedAt
ofjwt.StandardClaims
only compare against an int64 instead of theNumericDate
. Also probably solvable with a new struct - The functions
VerifyIssuedAt
,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 struct
Anything 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)