Les deux choix font référence à l'algorithme utilisé par le fournisseur d'identité pour signer le JWT. La signature est une opération cryptographique qui génère une "signature" (partie du JWT) que le destinataire du jeton peut valider pour s'assurer que le jeton n'a pas été falsifié.
RS256 (signature RSA avec SHA-256 ) est un algorithme asymétrique , et il utilise une paire de clés publique / privée: le fournisseur d'identité a une clé privée (secrète) utilisée pour générer la signature, et le consommateur du JWT obtient une clé publique pour valider la signature. Étant donné que la clé publique, contrairement à la clé privée, n'a pas besoin d'être sécurisée, la plupart des fournisseurs d'identité la rendent facilement accessible et utilisable par les consommateurs (généralement via une URL de métadonnées).
HS256 ( HMAC avec SHA-256), d'autre part, implique une combinaison d'une fonction de hachage et d'une clé (secrète) qui est partagée entre les deux parties utilisées pour générer le hachage qui servira de signature. Étant donné que la même clé est utilisée à la fois pour générer la signature et pour la valider, il faut veiller à ce que la clé ne soit pas compromise.
Si vous développez l'application consommant les JWT, vous pouvez utiliser le HS256 en toute sécurité, car vous aurez le contrôle sur qui utilise les clés secrètes. Si, en revanche, vous n'avez pas de contrôle sur le client, ou si vous n'avez aucun moyen de sécuriser une clé secrète, RS256 conviendra mieux, car le consommateur n'a besoin que de connaître la clé publique (partagée).
Étant donné que la clé publique est généralement disponible à partir des points de terminaison de métadonnées, les clients peuvent être programmés pour récupérer la clé publique automatiquement. Si tel est le cas (comme c'est le cas avec les bibliothèques .Net Core), vous aurez moins de travail à faire sur la configuration (les bibliothèques chercheront la clé publique sur le serveur). Les clés symétriques, en revanche, doivent être échangées hors bande (garantissant un canal de communication sécurisé) et mises à jour manuellement en cas de roulement de clé de signature.
Auth0 fournit des points de terminaison de métadonnées pour les protocoles OIDC, SAML et WS-Fed, où les clés publiques peuvent être récupérées. Vous pouvez voir ces points de terminaison sous les "Paramètres avancés" d'un client.
Le point de terminaison des métadonnées OIDC, par exemple, prend la forme de https://{account domain}/.well-known/openid-configuration
. Si vous accédez à cette URL, vous verrez un objet JSON avec une référence à https://{account domain}/.well-known/jwks.json
, qui contient la clé publique (ou les clés) du compte.
Si vous regardez les exemples RS256, vous verrez que vous n'avez pas besoin de configurer la clé publique n'importe où: elle est récupérée automatiquement par le framework.