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.
- this deprecates the use of `JWK.importKey` in favor of
`JWK.asKey`
- this deprecates the use of `JWKS.KeyStore.fromJWKS` in favor of
`JWKS.asKeyStore`
Both `JWK.importKey` and `JWKS.KeyStore.fromJWKS` could have resulted
in the process getting blocked when large bitsize RSA private keys
were missing their components and could also result in an endless
calculation loop when the private key's private exponent was outright
invalid or tampered with.
The new methods still allow to import private RSA keys with these
optimization key parameters missing but its disabled by default and one
should choose to enable it when working with keys from trusted sources
It is recommended not to use @panva/jose versions with this feature in
its original on-by-default form - v1.1.0 and v1.2.0 These will
