jose は、署名付きトークンと暗号化トークン、JWK のインポートとエクスポート、ローカルとリモートの JWK セットといった JOSE ファミリー全体を、あらゆる JavaScript ランタイムで同じ API によって扱えます。バージョン 6 以降はすべての暗号処理を WebCrypto で行うため、鍵は CryptoKey オブジェクトです(Node.js の KeyObject インスタンスも引き続き受け入れられます)。また、ライブラリは WebCrypto の曲線の一覧をそのまま引き継ぎます。ES256、ES384、ES512、EdDSA と Ed25519、そして 6.2.13 ではランタイムが提供していれば ML-DSA のアルゴリズムにも対応します。ES256K と Ed448 は ERR_JOSE_NOT_SUPPORTED で拒否されます。
重要な部分のデフォルトは厳格です。jwtVerify() は alg: none を決して受け入れず(署名のないトークンは別の UnsecuredJWT クラスでしか読めません)、鍵は 1 つのアルゴリズムファミリーに結び付けられます。そのため、EC 公開鍵で検証する HS256 トークンや、EC 鍵で検証する RS256 トークンは、検証を通らずに TypeError で失敗します。ES256 は P-384 の鍵も拒否します。それでも algorithms は指定してください。複数の種類の鍵を含む鍵セットでは、発行者が黙ってアルゴリズムを切り替えても受け入れないようにするのが、この指定の役割です。
2 つのデフォルトは、厳しい方向と緩い方向に分かれています。clockTolerance はゼロで厳格ですが、exp は任意で厳格ではありません。サンプルのように requiredClaims に列挙しない限り、有効期限のないトークンも検証を通ります。ECDSA 署名が DER で届いた JWS(クラウドの KMS や openssl dgst を使ってトークンを手作業で組み立てた場合によくあります)は、汎用的な signature verification failed で失敗し、エンコーディングが原因だと示すものは何もありません。JWT デバッガーなら署名の長さがひと目でわかり、DER ⇄ 生形式の変換ツールで修正できます。
鍵のインポートは明示的です。importSPKI と importPKCS8 は PEM 文字列を受け取り(DER のバイト列は "spki" must be SPKI formatted string で拒否されます)、importX509 は PEM 形式の証明書を、importJWK は JWK を受け取ります。OpenSSL がデフォルトで書き出す SEC1 の EC PRIVATE KEY ファイルは importPKCS8 で拒否されるため、たとえば JWK 変換ツールを使って、先に PKCS#8 に変換してください。
ID プロバイダーが発行したトークンを検証するには、プロバイダーの jwks_uri を指定して createRemoteJWKSet を使ってください。鍵をキャッシュし、未知の kid を受け取ると再取得し、再取得にはレート制限をかけます。プロバイダーが実際に公開している内容は JWKS チェッカーで確認してください。