Proof of Possession (PoP)

Répondant à la préoccupation exprimée dans la rubrique Authentifier l’application, la technique "preuve de possession" serait-elle ce dont nous avons besoin ?

La particularité de la PoP consiste à faire créer par l’application cliente une paire de clé publique-privée à chaque procédure d’authentification.

Il s’agit de certifier que l’application qui présente le JWT est bien celle qui a été identifiée au moment de l’authentification. Cependant, certifier que l’application est celle qui a initié l’authentification de l’utilisateur final n’est pas prouver que c’est l’application authentique. La preuve de possession n’est pas la preuve de l’identité de l’application et de son intégrité ( la conformité de son code au modèle d’origine ).

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, plus universelle (ne nécessitant pas la connaissance préalable d’une clé partagée entre le client et l’OP), demandant moins d’échanges et paraissant plus simple de mise en œuvre et, par-dessus tout, mieux sécurisée.

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.

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