Accueil > OpenID Connect OAuth Server par DnC > Développer > Proof of Possession (PoP)

Proof of Possession (PoP)

Répondant à la préoccupation exprimée dans la rubrique Authentifier l’application, la "preuve de possession" est ce dont nous avons besoin pour certifier que l’application qui présente le JWT est bien celle qui a été identifiée au moment de l’authentification.

La particularité de la PoP, telle que nous prévoyons de l’implémenter, consiste à faire créer par l’application cliente une paire de clé publique-privée à chaque procédure d’authentification.

Cependant, certifier que l’application est celle qui a été authentifiée n’est pas prouver que c’est l’application authentique.

Le terme « preuve de possession » fait référence à des mécanismes de chiffrement qui atténuent le risque de vol de jetons de sécurité et d’utilisation par un attaquant.
Dans le cas des jetons "porteur" ( Bearer Token ), la simple possession du jeton permet à une application de l’utiliser vis-à-vis d’une ressource protégée.

Le document rfc7800 - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) - propose une implémentation associé au JWT.
Nota : Nous sommes dans OpenID Connect. Nous remplaçons donc dans le texte :
"émetteur (issuer)" par "serveur OIDC (OpenID Provider)" ou OP,
"présentateur (presenter)" par "application cliente ou client ou RP",
Nous conservons "destinataire (recipient)" en gardant à l’esprit que ce peut être une "ressource protégée" ou RS, une API ou n’importe quel autre ressource ou encore l’OP lui-même si le jeton lui est retourné pour ré-authentification silencieuse.

Cette spécification explique comment déclarer dans un jeton Web JSON (JWT) que le client présentant le JWT possède une clé particulière preuve-de-possession et comment le destinataire peut obtenir de manière cryptographique la preuve que le présentateur possède la clé.

Le document présente deux implémentations : avec preuve de possession à clé symétrique ou asymétrique. Nous ne considérerons que la deuxième, demandant moins d’échanges et paraissant plus simple de mise en œuvre.

Le client génère une paire de clés publique / privée et envoie la clé publique à l’OP. L’OP crée un JWT contenant la clé publique (ou son identifiant).

Lorsque le client présente le JWT au destinataire, il doit produire la preuve-de-possession. Il présente un nonce signé avec la clé privée dans une déclaration ’cnf’.

Le destinataire peut vérifier qu’il interagit avec le client authentifié en extrayant la clé publique de la demande de confirmation du JWT (après vérification de la signature numérique du JWT) et en en vérifiant la signature du nonce.

Questions ...

Dans l’état actuel du développement exploratoire ( pas encore sur GitHub ), voici quelques questions :

- Pourquoi un malware ne serait-il pas capable de générer un PoP acceptable avec la technique décrite ? On obtient bien la preuve que l’application est celle avec laquelle l’utilisateur final a été authentifiée. Mais authentifié ne veut pas dire authentique. Dans le cas d’une application avec back-end, l’application peut être identifiée avec certitude comme étant le modèle original. Mais dans le cas d’une application sans back-end ( une copie de l’original fournie par le serveur ), un malware peut s’exécuter dans le même user-agent, ce qui ouvre notamment la possibilité de tromper l’utilisateur (physhing) auquel il revient d’identifier l’application.

- Cela permet-il de sécuriser un flux implicite ? La clé privée est-elle exposée par une application "sans backend" (la clé privée est calculée et utilisée une seule fois dans le même thread) ? Exposer la clé privée serait contraire au principe même de la cryptographie asymétrique et ôterait toute valeur au PoP.

Il existe des informations complémentaires, connectez vous pour les voir.