1. Introduction
1. Introduction
Le cadre d'autorisation OAuth 2.0 [RFC6749] permet aux applications clientes tierces d'obtenir un accès délégué aux ressources protégées. Dans le flux OAuth abstrait typique illustré par la figure 1, le client obtient un jeton d'accès auprès d'une entité appelée serveur d'autorisation, puis utilise ce jeton pour accéder aux ressources protégées, telles que les API HTTPS.
+--------+ +---------------+
| | | |
| |<--(A)-- Obtenir jeton d'accès -->| Serveur |
| | | d'autorisation|
| | | |
| | +---------------+
| | ^
| | |
| |
| | (C) |
| Client | Valider le jeton
| | d'accès |
| |
| | |
| | v
| | +---------------+
| | | (C) |
| | | |
| |<-(B)-- Utiliser jeton d'accès -->| Ressource |
| | | protégée |
| | | |
+--------+ +---------------+
Figure 1 : Flux abstrait du protocole OAuth 2.0
Le flux illustré par la figure 1 comprend les étapes suivantes :
(A) Le client envoie une requête HTTPS « POST » au serveur d'autorisation et présente un justificatif représentant l'octroi d'autorisation. Pour certains types de clients (ceux auxquels ont été délivrés ou qui ont autrement établi des identifiants client), la requête doit être authentifiée. Dans la réponse, le serveur d'autorisation délivre un jeton d'accès au client.
(B) Le client inclut le jeton d'accès lorsqu'il effectue une requête pour accéder à une ressource protégée.
(C) La ressource protégée valide le jeton d'accès afin d'autoriser la requête. Dans certains cas, par exemple lorsque le jeton est autonome et protégé cryptographiquement, la validation peut être effectuée localement par la ressource protégée. Dans d'autres cas, la ressource protégée doit interroger le serveur d'autorisation pour déterminer l'état du jeton et obtenir des méta-informations à son sujet.
En s'appuyant sur le flux abstrait ci-dessus, ce document normalise des options de sécurité renforcées pour OAuth 2.0 utilisant le mutual TLS fondé sur des certificats client. La section 2 fournit des options pour authentifier la requête à l'étape (A). L'étape (C) est prise en charge par des sémantiques exprimant la liaison du jeton au certificat client pour un traitement local et distant, respectivement aux sections 3.1 et 3.2. Cela garantit que, comme décrit à la section 3, l'accès à la ressource protégée à l'étape (B) n'est possible que pour le client légitime utilisant un jeton lié au certificat et détenant la clé privée correspondant au certificat.
OAuth 2.0 définit une méthode d'authentification client par secret partagé mais permet également de définir et d'utiliser des mécanismes d'authentification client supplémentaires lors d'interactions directes avec le serveur d'autorisation. Ce document décrit un mécanisme supplémentaire d'authentification client utilisant l'authentification mutual-TLS par certificat, qui offre de meilleures caractéristiques de sécurité que les secrets partagés. Alors que [RFC6749] documente l'authentification client pour les requêtes vers le point de terminaison de jeton, les extensions d'OAuth 2.0 (telles que l'introspection [RFC7662], la révocation [RFC7009] et le point de terminaison d'authentification backchannel dans [OpenID.CIBA]) définissent des points de terminaison qui utilisent également l'authentification client, et les méthodes mutual-TLS définies ici s'appliquent également à ces points de terminaison.
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 diffère du cas du jeton porteur décrit dans [RFC6750], où toute partie en possession du jeton d'accès peut l'utiliser pour accéder aux ressources associées. Lier un jeton d'accès au certificat du client empêche l'utilisation de jetons volés ou la relecture de jetons par des parties non autorisées.
Les jetons d'accès liés au certificat mutual-TLS et l'authentification client mutual-TLS sont des mécanismes distincts, complémentaires, qui n'ont pas nécessairement à être déployés ou utilisés ensemble.
Ce document introduit des paramètres de métadonnées client supplémentaires pour prendre en charge les jetons d'accès liés au certificat et l'authentification client mutual-TLS. Le serveur d'autorisation peut obtenir les métadonnées client via le protocole d'enregistrement dynamique de client [RFC7591], qui définit des mécanismes pour enregistrer dynamiquement les métadonnées client OAuth 2.0 auprès des serveurs d'autorisation. De plus, les métadonnées définies par [RFC7591] et les extensions enregistrées qui y sont associées impliquent un modèle de données général pour les clients utile aux implémentations de serveur d'autorisation, même lorsque le protocole d'enregistrement dynamique de client n'est pas utilisé. De telles implémentations disposeront en général d'une interface utilisateur de gestion de la configuration client.