As per https://tools.ietf.org/html/rfc7797 abstract
This specification updates RFC 7519 by stating that JSON Web Tokens
(JWTs) MUST NOT use the unencoded payload option defined by this
specification.
BREAKING CHANGE: Revised, Promise-based API
BREAKING CHANGE: No dependencies
BREAKING CHANGE: Browser support (using [Web Cryptography API](https://www.w3.org/TR/WebCryptoAPI/))
BREAKING CHANGE: Support for verification using a remote JWKS endpoint
BREAKING CHANGE: Experimental Node.js libuv thread pool based runtime (non-blocking 🎉)
BREAKING CHANGE: the `JWT.verify` profile option was removed, use e.g.
`JWT.IdToken.verify` instead.
BREAKING CHANGE: removed the `maxAuthAge` `JWT.verify` option, this
option is now only present at the specific JWT profile APIs where the
`auth_time` property applies.
BREAKING CHANGE: removed the `nonce` `JWT.verify` option, this
option is now only present at the specific JWT profile APIs where the
`nonce` property applies.
BREAKING CHANGE: the `acr`, `amr`, `nonce` and `azp` claim value types
will only be checked when verifying a specific JWT profile using its
dedicated API.
BREAKING CHANGE: using the draft implementing APIs will emit a one-time
warning per process using `process.emitWarning`
> NumericDate
> A JSON numeric value representing the number of seconds from
> 1970-01-01T00:00:00Z UTC until the specified UTC date/time,
> ignoring leap seconds. This is equivalent to the IEEE Std 1003.1,
> 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in
> which each day is accounted for by exactly 86400 seconds, other
> than that non-integer values can be represented. See RFC 3339
> [RFC3339] for details regarding date/times in general and UTC in
> particular.
I'm done trying to educate other JOSE producers about interoperability
so i'm going to be accepting their non-conform base64url so that users
of this module don't suffer performance loss.
validating that iat is in the past is common sense but actually nowhere
defined, in most applications tokens will contain `exp` and for those
it seems requiring a few second leeway just to satisfy `iat` seems
inappropriate
It is now possible to pass a profile to `JWT.verify` and have the JWT
validated according to it. This makes sure you pass all the right
options and that required claims are present, prohibited claims are
missing and that the right JWT typ is used.
More profiles will be added in the future.
