jose4j implements JWS, JWE, JWK and JWT on the JDK's own providers, with JsonWebSignature for signing and a JwtConsumer built by JwtConsumerBuilder for verification and claims checks. 0.9.7 round-tripped HS, RS, PS and ES at 256/384/512 and EdDSA; ES256K, Ed25519 and Ed448 are not recognised algorithm names.
The defaults block the two classic attacks but leave the algorithm open. none is refused ('none' is a blocked algorithm.) unless signatures are switched off explicitly, and the key type has to fit: an RS256 token against an EC key and an HS256 token keyed with the EC key's PEM text both failed (cannot be used for HMAC verification). Any other algorithm the key can perform is accepted, though, so pin it with setJwsAlgorithmConstraints(ConstraintType.PERMIT, ...), as the sample does. An HmacKey built from the PEM bytes verified the forged HS256 token — keys must come from configuration, never from what the token claims.
Key sizes are enforced: ES256 refuses a P-384 key (expects a key using P-256 but was P-384) and HS256 refused a 16-byte key because RFC 7518 requires keys at least as long as the hash output. ES256 signatures are the 64-byte raw r‖s; a DER signature fails with Invalid JWS Signature — the JWT debugger shows the length.
Claims defaults cut both ways: no clock skew allowance is stricter than most teams expect, and no required exp is looser. setRequireExpirationTime(), setExpectedIssuer(), setExpectedAudience() and setAllowedClockSkewInSeconds() belong in every consumer that reads tokens from another service.
For encrypted tokens, the JWE inspector shows what a jose4j-produced JWE contains.