PS384: RSASSA-PSS with SHA-384 in a JWT

Everything in PS256 applies here with SHA-384 substituted throughout: the message digest, the mask generation function and the salt length all move together. That last one is the detail worth knowing, because PSS implementations often let the caller choose a salt length and JOSE does not: RFC 7518 pins it to the hash output size, so a library configured with a different salt length produces signatures that conforming verifiers reject.

Padding consumes room inside the RSA modulus, and a longer hash consumes more of it. With a 2048 bit key there is ample space for SHA-384 with a 48 byte salt, so this is not a limit anyone meets in JWT deployments, but it is why very small RSA keys cannot support the larger PSS variants at all. It is another reason the 2048 bit minimum is not merely conservative.

You will meet PS384 mostly in estates that standardized on SHA-384 for everything, often because certificates and code signing were specified that way first and tokens inherited the rule. Chosen on its own merits it is hard to justify over PS256, which has the broader implementation support and the same padding scheme.

The decoder verifies PS384 in the browser given a PEM public key. That is worth checking early when integrating with a partner, because unsupported algorithm failures and invalid signature failures often surface as the same generic error message at the API boundary, and a local verification separates them immediately.