jose4j реализует JWS, JWE, JWK и JWT на собственных провайдерах JDK: для подписи служит JsonWebSignature, а для проверки подписи и утверждений — JwtConsumer, созданный через JwtConsumerBuilder. В версии 0.9.7 подпись и проверка работали для HS, RS, PS и ES в вариантах 256/384/512 и для EdDSA; ES256K, Ed25519 и Ed448 библиотека не распознаёт как имена алгоритмов.
Настройки по умолчанию блокируют две классические атаки, но оставляют алгоритм открытым. none отклоняется ('none' is a blocked algorithm.), если явно не отключить требование подписи, а тип ключа должен подходить к алгоритму: токен RS256 при проверке ключом EC и токен HS256, подписанный текстом PEM ключа EC, не прошли проверку (cannot be used for HMAC verification). Однако любой другой алгоритм, который может выполнить ключ, принимается, поэтому зафиксируйте алгоритм через setJwsAlgorithmConstraints(ConstraintType.PERMIT, ...), как это делает пример. С HmacKey, созданным из байтов PEM, поддельный токен HS256 прошёл проверку: ключи должны браться из конфигурации и никогда — из того, что заявляет токен.
Размеры ключей проверяются: ES256 не принимает ключ P-384 (expects a key using P-256 but was P-384), а HS256 отклонил 16-байтовый ключ, потому что RFC 7518 требует ключей не короче выхода хеш-функции. Подписи ES256 — это 64-байтовый формат raw r‖s; подпись DER не проходит проверку с ошибкой Invalid JWS Signature, а её длину покажет отладчик JWT.
Проверка утверждений по умолчанию строга в одном и мягка в другом: допуска на расхождение часов нет, и это строже, чем ожидает большинство команд, а exp необязателен, и это, наоборот, мягче ожидаемого. setRequireExpirationTime(), setExpectedIssuer(), setExpectedAudience() и setAllowedClockSkewInSeconds() должны быть в каждом JwtConsumer, который читает токены другого сервиса.
Если токены зашифрованы, инспектор JWE покажет, что содержит JWE, созданный jose4j.