An implementation of the JOSE suite of IETF standards and the closely related JWT (JSON web token) spec (https://tools.ietf.org/html/rfc7519/).
Both signed and encrypted JWTs are supported, as well as simple JWK keys.
User ByteArray and ScrubbedBytes from memory package in preference to ByteString in internal crypto code.
- Fixed exception when JWT contained invalid Base64 (issue #15).
- Add generateSymmetricKey utility function to Jwk module.
A JWT parser is now used to separate parsing and decoding into separate stages (internal change).
Stricter checking of AES key lengths when looking for a valid JWK to encode/decode an AES-KW JWT.
Add JSON test data to extra-source-files.
Remove test dependency on aeson-qq
- Update cryptonite version to 0.19 to avoid security issues
- Fix broken benchmark code
- Better error message for invalid key length when using AES keywrap
- Add support for AES key wrap in JWEs.
- Support A192GCM and A192CBC-HS384 algorithms.
- Switch to cryptonite library.
Remove dependency on
Minor internal changes to fix build on GHC 7.10.
- Change KeyId type to allow use of a UTCTime string for the identifier.
- Internal crypto fixes to prevent exceptions from external libraries.
Add JwtEncoding type. Changes API of
Fix in the code for finding suitable JWKs for encoding/decoding.
doctestflag to cabal file to allow doctests to be disabled.
Add cprng-aes dependency to doctests to stop test failure on travis and nixos hydra builds.
- Changed use of
Jwttype to represent an encoded JWT.
Payloadtype to allow setting the
ctyheader value correctly for nested JWTs.
- Added an explicit
Unsecuredtype for a decoded JWT, to make it obvious when the content is not signed or encrypted.
- Fixed some bugs in JSON encoding and decoding of EC JWKs.
Changed the signature of
Jwt.encode to take a list of
Jwk rather than a single key. The key will be selected from
the list based on the specified algorithms.
- New support for JWS validation using elliptic curve algorithms.
Jwt.encodefunction which takes a JWK argument, allowing key data (currently the key ID) to be encoded in the token header.