Appendix B. Relationship to Token Binding (Rapport avec Token Binding)
Appendix B. Relationship to Token Binding (Rapport avec Token Binding)
OAuth 2.0 Token Binding [TOKEN] permet d'appliquer Token Binding aux différents artefacts et jetons utilisés dans OAuth. Cela inclut la liaison d'un jeton d'accès à une clé Token Binding, qui présente des similitudes de motivation et de conception avec les jetons d'accès liés au certificat client mutual-TLS définis dans le présent document. Les deux documents définissent ce que l'on appelle souvent un mécanisme de sécurité de preuve de possession (proof-of-possession) pour les jetons d'accès, selon lequel un client doit démontrer la possession de matériel de clé cryptographique lorsqu'il accède à une ressource protégée. Les détails diffèrent quelque peu entre les deux documents, mais dans les deux cas le serveur d'autorisation lie le jeton d'accès qu'il délivre à une paire de clés asymétriques détenue par le client. Le client prouve ensuite la possession de la clé privée de cette paire par rapport à la connexion TLS sur laquelle la ressource protégée est accessible.
Token Binding utilise des clés brutes générées sur le client, ce qui évite nombre de difficultés liées à la création, à la distribution et à la gestion des certificats utilisés dans cette spécification. Toutefois, au moment de la rédaction, Token Binding est relativement récent et son support reste limité dans les plateformes de développement d'applications et les outils disponibles. Tant que le support des spécifications fondamentales sous-jacentes de Token Binding ne sera pas meilleur, des implémentations pratiques d'OAuth 2.0 Token Binding restent peu réalisables. Mutual TLS, en revanche, existe depuis un certain temps et bénéficie d'un support étendu dans les serveurs web et les plateformes de développement. En conséquence, l'authentification client OAuth 2.0 Mutual-TLS et les jetons d'accès liés au certificat peuvent être construits et déployés dès maintenant avec les plateformes et outils existants. À l'avenir, les deux spécifications seront probablement déployées en parallèle pour résoudre des problèmes analogues dans des environnements différents. Les serveurs d'autorisation peuvent même prendre en charge les deux spécifications simultanément, en utilisant des mécanismes distincts de preuve de possession (proof-of-possession) pour les jetons délivrés à différents clients.