jsonwebtoken は、encode、decode、Validation オブジェクトを使って JWT をエンコード・デコードし、クレームには serde を使います。バージョン 10 以降、暗号処理はフィーチャーフラグで選ぶバックエンド(aws_lc_rs または rust_crypto)が担い、チェックでは aws_lc_rs を使いました。フィーチャーを指定し忘れてもビルドは失敗しません。デフォルトのフィーチャーだけを使うと、11.1.0 はコンパイルに成功したうえで、最初の encode() で Could not automatically determine the process-level CryptoProvider というパニックを起こしました。サンプルのマニフェストのように、バックエンドをちょうど 1 つだけ有効にしてください。
アルゴリズムは閉じた列挙型です。256/384/512 の HS、RS、PS と ES256、ES384、EdDSA はすべて署名と検証ができましたが、ES512、ES256K、Ed25519 はそもそもバリアントとして存在しません。none のバリアントもないため、署名のないトークンはヘッダーの解析中に unknown variant none で失敗します。Validation::new(alg) が許可リストです。Validation::new(ES256) でチェックした HS256 トークンは InvalidAlgorithm で失敗しました。両方のアルゴリズムを許可した場合でも、EC 公開鍵の PEM テキストを鍵とした HS256 トークンは InvalidKeyFormat で失敗しました。EC の DecodingKey は HMAC シークレットとして機能できないためです。
クレームのチェックはほとんどのライブラリより厳格です。exp のないトークンは Missing required claim: exp で失敗します。一方、時刻のずれの許容はデフォルトで 60 秒で、57 秒前に期限切れになったトークンも検証を通りました。サンプルのように leeway を小さくし、Validation に発行者とオーディエンスを設定してください。ES256 は署名時に P-384 の鍵を InvalidEcdsaKey で拒否します。
ES256 の署名は JWS が求める 64 バイトの生の r‖s で、DER の署名は InvalidSignature で失敗します。鍵は PEM(from_ec_pem、from_rsa_pem、from_ed_pem)と DER から読み込めます。Ed25519 の DER では、エンコード用の鍵は PKCS#8 を、デコード用の鍵は 32 バイトの生の公開鍵を受け取りました。トークンは JWT デバッガーで解析し、HMAC シークレットは JWT シークレットチェッカーで確認してください。
JWT 以外の署名には、バックエンドのクレート(aws-lc-rs または RustCrypto ecdsa)を直接使ってください。