Référence : RFC 7516
Ce document définit deux formes de sérialisation pour représenter la charge utile chiffrée : la sérialisation compacte JWE et la sérialisation JWE JSON.
Nous traiterons la sérialisation compacte, qui est la seule à produire un JWT sécurisé pour l’URL (Url safe).
Sérialisation compacte JWE
Avec la sérialisation compacte JWE, un jeton JWT est construit avec cinq composants clés, chacun séparé par un point (.) : En-tête JOSE, clé cryptée JWE, vecteur d’initialisation JWE, données d’authentification supplémentaires (AAD) JWE, charge utile chiffrée JWE et balise d’authentification JWE :
JOSE header . JWE Encrypted Key . JWE initialization vector . JWE Ciphertext . JWE Authentication Tag
Cryptage symétrique, Mode de gestion de clé
Le principe général du JWE consiste à crypter un contenu avec un algorithme de cryptage symétrique. Il est donc nécessaire que les deux parties, émetteur et destinataire, utilisent une même clé de chiffrement du contenu (CEK) .
Le Mode de gestion de clé est la façon d’indiquer au destinataire comment il doit déterminer la valeur de la clé CEK.
Traduction d’un extrait de la RFC 7516 :
Mode de gestion de clé
Méthode de détermination du chiffrement de la valeur de clé de chiffrement du contenu (CEK) à utiliser.
Chaque algorithme utilisé pour déterminer la valeur CEK utilise un Mode de gestion de clé. Les Modes de gestion de clé utilisés par cette spécification sont : (...)Chiffrement de clé (Key Encryption)
Un mode de gestion des clés dans lequel la valeur CEK est chiffrée pour le
destinataire prévu en utilisant un algorithme de chiffrement asymétrique.Encapsulation de clé (Key Wrapping)
Un mode de gestion des clés dans lequel la valeur CEK est chiffrée pour le
destinataire prévu à l’aide d’un algorithme d’encapsulation de clé symétrique.Accord de clé directe (Direct Key Agreement)
Un mode de gestion des clés dans lequel un algorithme d’accord de clé est utilisé
pour convenir de la valeur CEK.Accord de clé avec encapsulation de clé (Key agreement with Key Wrapping)
Un mode de gestion des clés dans lequel un algorithme d’accord de clé est utilisé
pour convenir d’une clé symétrique utilisée pour chiffrer la valeur CEK pour le
destinataire prévu à l’aide d’un algorithme d’encapsulation de clé symétrique.Cryptage direct (Direct Encryption)
Un mode de gestion de clé dans lequel la valeur CEK utilisée est la valeur du secret de clé symétrique partagé entre les parties.
Deux modes sont particulièrement utilisés : le cryptage direct ( symétrique ) pour sa simplicité et le chiffrement de clé ( asymétrique ) qui est parfaitement adapté à des applications inscrites sur un serveur OIDC.
Mode de gestion "Cryptage direct" : Choix de la clé de chiffrement
Dans ce mode, le contenu du JWE est crypté avec un algorithme symétrique. Pour le décrypter, nous avons besoin d’une clé CEK connue à la fois par l’application émettant le JWE et le serveur OAuthSD. Le mode de gestion de clé "Cryptage direct" est le mode de partage le plus simple : la clé est un secret partagé "hors ligne" entre les deux parties.
La clé CEK ne doit pas être la clé publique d’un client, ni aucune autre donnée publique !
Il ne peut pas non plus s’agir de la clé privée d’un client, car elle doit rester secrète à l’intérieur de l’OP.
Cas d’un "jeton au porteur" (Bearer Token)
Lorsqu’une ressource protégée présente à l’Introspection un jeton en provenance d’une application, il s’agit d’un "jeton au porteur" (Bearer Token).
Lorsque le contrôleur d’Introspection reçoit le JWE, il ne peut pas déterminer l’application avant le décryptage (contrairement au cas d’un JWT). Ainsi, le secret CEK ne peut être qu’une valeur prédéterminée à l’intérieur d’un groupe privé d’applications et de ressources protégées, contrôlées par un même serveur OAuthSD.
Cas d’un jeton JWE utilisé dans un protocole PoP
Dans le cas de la preuve de possession apportée par une application (PoP), ou d’autres protocoles d’identification d’application mis en œuvre par OAuthSD, l’application qui présente le jeton JWE communique son identifiant client_id en même temps que le jeton avec le paramètre supplémentaire ’aud’ (audience).
Il est alors possible d’utiliser le secret de l’application cliente comme clé de chiffrement de contenu (CEK).
Il faudra veiller à ce que le secret ne soit pas révélé par une mauvaise utilisation dans le cadre d’une application sans backend.
Avantages et inconvénients du cryptage direct
Le cryptage direct est le plus simple à programmer, et donc le plus souvent utilisé. Mais il est compliqué à exploiter, car le partage "hors ligne" de la clé avec de nombreux clients est fastidieux, et la mise à jour plus encore. A cela s’ajoute le risque de compromission inhérent à une transmission "hors ligne".
Mode de gestion "Chiffrement de clé"
Dans le cas de jetons JWE émis par des applications clientes enregistrées sur le serveur OAuthSD, nous avons tout ce qu’il faut pour gérer un chiffrement asymétrique de la clé CEK, une paire de clés publique/privée étant attachée à chaque application.
La clé publique sera utilisée pour le chiffrement.
Pour le déchiffrement, il n’est pas question de passer la clé privée à une application publique. Il ne serait pas non plus de bonne pratique de la passer à une application de confiance, sauf peut-être sur le même serveur ou groupe de serveurs co-localisés. Le déchiffrement et la validation du jeton sera donc effectué sur le serveur, avec un contrôleur Introspect adapté à JWE.
Introspection d’un jeton JWE
Dans le serveur OAuthSD , le contrôleur Introspection peut recevoir un jeton d’identité ID chiffré avec JWE aussi bien qu’un jeton ID JWT standard.
Si un jeton JWE est reconnu, il est déchiffré et le processus se poursuit avec la charge utile du JWE, qui n’est autre que le JWT.
Cas d’usage de JWE
Dans l’utilisation courante du jeton d’identité (ID Token), la charge utile ne comporte pas de données sensibles.
Cependant, dans le cas où des données supplémentaires sont incorporées dans le jeton, comme par exemple :
des droits particuliers accordés à un utilisateur,
des éléments de configuration de l’application cible en fonction d’un utilisateur, etc.
Il devient utile de masquer ces données.
Rien n’empêche également de se servir du JWE de façon extensive pour transporter des informations de façon protégée, ce qui, dans certaines applications, permettrait d’éviter d’exposer des données sensibles à l’aide de web services (ou ressources protégées).
Attention ! JOSE n’est pas sûr !
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
RSS 2.0