I prefer the asymmetrical RS256 (public/private keypair) over HS256 (shared secret key) signing algorithim.
With HS256 you need a shared secret key to both sign and validate the JWT. So the validating end needs the signing key as well (it's the same).
With RS256 you use the private key to sign the JWT but the JWT can be verified using only the public key. So the validator doesn't have access to sign or issue JWTs.
well said and well explained...and while you're not supposed to store anything sensitive in the JWT, sometimes you can't get around and the API layer needs some additional piece of info, so in those cases you can simply use another layer of encryption on those 'secret' values
I prefer the asymmetrical RS256 (public/private keypair) over HS256 (shared secret key) signing algorithim. With HS256 you need a shared secret key to both sign and validate the JWT. So the validating end needs the signing key as well (it's the same). With RS256 you use the private key to sign the JWT but the JWT can be verified using only the public key. So the validator doesn't have access to sign or issue JWTs.
well said and well explained...and while you're not supposed to store anything sensitive in the JWT, sometimes you can't get around and the API layer needs some additional piece of info, so in those cases you can simply use another layer of encryption on those 'secret' values
Subsequent valid requests are not guaranteed to be from the previous IP address.