See the longer answer on recommended algorithm for JWT, the one line answer is to go with RS256 (RSA 2048 bits with SHA 256).
JWT tokens support a few signature schemes, mainly: RSA (RS256), ECDSA (ES256) and HMAC (HS256).
HMAC is a specialized symmetric signature mode that is specific to JWT. It has no practical use cases as far as I am aware, you're better off ignoring it entirely.
In HMAC, the application and the identity provider share ONE secret passphrase. The passphrase is used to both create and verify tokens.
It's odd when one thinks about it, because it allows both the client and the identity server to create authentication tokens. The "normal" mode of operation is only for the identity server (Google, Facebook auth, internal Active Directory, etc...) to authenticate users and create JWT tokens. It makes no sense for clients to manufacture tokens.
In theory, HMAC could be used in some exotic app2app use cases, but those are already covered -and more secure- when using normal signatures (RSA/ECDSA), so there are no practical applications for HS256.
- transitive trust: Google and Apple auth could trust one another, sharing one secret passphrase to craft and communicate internal tokens to one another.
Except federated authentication is already supported by regular signatures out-of-the-box and more easily. There is no reason to prefer a secret passphrase, it takes extra work to share the secret passphrase across organizations and both organizations will be compromised if either leaks the secret.
- app2app authentication: a service can authenticate to the identify server to obtain a JWT token for itself and communicate with other services (that are protected by authentication).
Except programmatic authentication is already supported out-of-the-box using username/password or certificate authentication. There is no reason to prefer a secret passphrase.
I do authentication for a living, I've implemented all these use cases in some companies. Deep in the abyss of the spec, in the
client_credentials grant in service to service authentication (besides client certificate authentication), there are things about clients signing JWT tokens. I'm 99% sure that's the only place where shared secret mode could be used (in a non insane way) and why the mode is supported at all in the spec... and all that's there is better covered by using certificate authentication.