#jwt #oidc #open-id #jws #connect #applications


Minimal implementation of JWT for OIDC and other applications

27 releases

0.4.1 May 1, 2024
0.3.5 Mar 12, 2024
0.3.3 Nov 30, 2023
0.2.9 Nov 7, 2022
0.1.7 Nov 13, 2021

#87 in Authentication

Download history 7794/week @ 2024-01-29 9502/week @ 2024-02-05 11414/week @ 2024-02-12 4703/week @ 2024-02-19 13314/week @ 2024-02-26 5636/week @ 2024-03-04 9586/week @ 2024-03-11 8670/week @ 2024-03-18 13652/week @ 2024-03-25 14540/week @ 2024-04-01 6120/week @ 2024-04-08 7158/week @ 2024-04-15 8448/week @ 2024-04-22 9900/week @ 2024-04-29 6558/week @ 2024-05-06 10627/week @ 2024-05-13

35,729 downloads per month
Used in 15 crates (6 directly)

MPL-2.0 license

4.5K SLoC

Compact JWT / JWE

Json Web Tokens (JWT) are a popular method for creating signed transparent tokens that can be verified by clients and servers. They are enshrined in standards like OpenID Connect which causes them to be a widespread and required component of many modern web authentication system.

Json Web Encryption (JWE) is an occasionally used method for sending secrets to a recipient or to create opaque tokens for services.

JWE, JWT, and Json Web Signature (JWS) however have a long track record of handling issues, which have led to security issues. This library will not be a complete implementation of JWE/JWT/JWS, instead focusing on a minimal subset that can be secured and audited for correctness more closely within a limited set of use cases.

When should I use this library?

If you are:

  • creating ECDSA signed JWT tokens, or verify ECDSA signed JWT tokens
  • implementing OIDC as a relying party or authorisation server
  • wanting to use HMAC signatures for transparent json data
  • needing a minimal secure JWS implementation
  • using TPM bound keys for signing JWTs
  • creating opaque encrypted tokens protected with AES-128-GCM
  • receiving or sending encrypted data to an ECDSA key

Then this library is for you

If you need non-compact JWS, or other complex use cases, this library is not for you.

Why another JWT library?

There are already many other libraries for JWT on crates.io however they each have a limitation or design that conflicts with the project goals in Kanidm. Examples are:

  • Incorrect Implementations - There are a number of JWT libraries in Rust that are incorrect to the RFC or do not have RFC vector tests
  • Ring as the sole cryptographic provider - we need to use OpenSSL
  • Only supporting RSA/Weak cryptographic algos - We want to use ECDSA
  • Full JWS implementation - As mentioned, JWS has a number of sharp edges like alg=none
  • No library supports pkcs11 or TPMS - We aim to allow hardware security modules to store private keys

As a result, nothing "fit" what we wanted, so we are making another library.


~151K SLoC