Liaison du jeton à la connexion TLS (TLS Token Binding)

Avertissement : à ce jour (début 2021), cette technique ne semble pas opérationnelle du fait de la complexité de son intégration dans les navigateurs. Faut-il l’abandonner ou attendre encore ?

Un jeton ne devrait fonctionner que pour le client auquel il a été émis, sinon nous nous retrouvons avec une catastrophe majeure en matière de sécurité. La liaison du jeton est conçue pour corriger la faiblesse du "Jeton au porteur" (Bearer Token), en rendant le jeton inutilisable dans une connexion TLS (HTTPS) établie par un client autre que le détenteur légitime.

Mais cela n’apporte rien de nouveau au problème de l’identification de l’application et de son intégrité, puisque c’est l’application elle-même qui génère la clé et puisque c’est le navigateur qui est identifié.

Références

OpenID Connect Token Bound Authentication 1.0 - draft 04
Cette spécification permet aux implémentations OpenID Connect d’appliquer la liaison jeton-TLS jeton au jeton ID OpenID Connect. Cela lie cryptographiquement le jeton d’identité aux connexions TLS sur lesquelles l’authentification s’est produite. Cette utilisation de la liaison de jetons protège le flux d’authentification contre les attaques de réexportation et de réexécution de jetons et de man-in-the-middle.

OAuth 2.0 Token Binding.
La section 5.2 de ce document reste valable dans le cas d’OpenID Connect pour sécuriser le code d’autorisation dans le cas des clients Web Services :

5.2. Web Server Clients
Cette section décrit une méthode PKCE adaptée aux clients de serveur Web, qui lie cryptographiquement le code d’autorisation à un jeton Paire de clés de liaison sur le navigateur. Le code d’autorisation est lié à l’ID de liaison de jeton que le navigateur utilise pour fournir le code d’autorisation à un client de serveur Web, qui est envoyé au serveur d’autorisation en tant qu’ID de liaison du jeton référencé pendant la demande d’autorisation. Le client du serveur Web transmet le jeton ID de liaison au serveur d’autorisation lors de la création du jeton d’accès avec la demande de code d’autorisation. Cette liaison garantit que le code d’autorisation ne peut pas être lu ou rejoué avec succès sur le client du serveur Web à partir d’un navigateur différent de celui qui a créé la demande d’autorisation.

RFC 8705
OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
Ce document décrit un mécanisme d’authentification du client utilisant l’authentification mutuelle réalisée avec des certificats TLS qui offre de meilleures caractéristiques de sécurité que le secret du client inscrit sur l’OP.

Les jetons d’accès liés au certificat Mutual-TLS garantissent que seule la partie en possession de la clé privée correspondant au certificat peut utiliser le jeton pour accéder aux ressources associées. Une telle contrainte est parfois appelée confirmation de clé, preuve de possession ou détenteur de clé et est différente du cas du jeton porteur décrit dans la [RFC6750], où toute partie en possession du jeton d’accès peut l’utiliser. pour accéder aux ressources associées. La liaison d’un jeton d’accès au certificat du client empêche l’utilisation de jetons d’accès volés ou la relecture de jetons d’accès par des parties non autorisées.

Mutual-TLS certificate-bound access tokens versus mutual-TLS client authentication
TBC

OpenID Connect : la bonne façon de passer l’ID de liaison

En transmettant avec le jeton JWT des informations dont l’intégrité peut-être vérifiée au moyen de la signature, OpenID Connect apporte un bénéfice essentiel par rapport à OAuth 2.0 : l’ID de liaison du jeton est incorporé à la charge utile du JWT et se trouve donc certifié par la signature.

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