Seems little too obvious to exist, but people make mistakes.
It’s just that with JWT/JSE/JOSE already questionable security options that you would be extra super careful if you are using it. (Biggest flaw off the top of my head is it literally says what encryption is used with a NONE option meaning you can just switch to “none” and forge jwts to anyone that didn’t know not to accept those, second would be that they mix symmetric and asymmetric encryption options)
I noticed after reading your comment that HS256 is marked as “required” for compliant implantations. In practice, I have only ever seen signers implement RS256 though...
In OIDC you can actually specificy supported key types in the discovery process and the IdP always decides the key type anyway.
HS256 relies in shared secrets, so anyone who can verify a token can also change it. RS256 allows you to download the IdP keychain every once in a while and verify tokens offline.
Yes, that’s what I meant. I only see RS256 implemented by identity providers (and advertised via .well-known/openid-configuration). This makes sense, since most identity providers are decoupled from their clients and thus cannot feasibly share a symmetric key. I am confused what is meant in the JWA specification[1] by “HS256: required” under “implementation requirements” in the table of allowed values (the entry for RS256 reads “recommended” for that column).
Seems little too obvious to exist, but people make mistakes.
It’s just that with JWT/JSE/JOSE already questionable security options that you would be extra super careful if you are using it. (Biggest flaw off the top of my head is it literally says what encryption is used with a NONE option meaning you can just switch to “none” and forge jwts to anyone that didn’t know not to accept those, second would be that they mix symmetric and asymmetric encryption options)