3. Mutual-TLS Client Certificate-Bound Access Tokens (Jetons d'accès liés au certificat client mutual-TLS)
3. Mutual-TLS Client Certificate-Bound Access Tokens (Jetons d'accès liés au certificat client mutual-TLS)
Lorsque le client utilise mutual TLS sur la connexion vers le point de terminaison de jeton, le serveur d'autorisation peut lier le jeton d'accès délivré au certificat client. Une telle liaison s'obtient en associant le certificat au jeton d'une manière accessible à la ressource protégée, par exemple en intégrant l'empreinte du certificat directement dans le jeton d'accès délivré, selon la syntaxe décrite à la section 3.1, ou par introspection de jeton comme décrit à la section 3.2. Lier le jeton d'accès au certificat client de cette façon a l'avantage de découpler cette liaison de l'authentification du client auprès du serveur d'autorisation, ce qui permet à mutual TLS lors de l'accès à la ressource protégée de servir uniquement de mécanisme de preuve de possession. D'autres méthodes d'association d'un certificat à un jeton d'accès sont possibles, d'un commun accord entre le serveur d'autorisation et la ressource protégée, mais elles dépassent le champ de la présente spécification.
Pour qu'un serveur de ressources utilise des jetons d'accès liés au certificat, il doit savoir à l'avance que mutual TLS sera utilisé pour une partie ou la totalité des accès aux ressources. En particulier, le jeton d'accès lui-même ne peut pas servir d'entrée à la décision de demander ou non mutual TLS, car (du point de vue TLS) il s'agit de « Application Data », échangée seulement après la fin de la poignée de main TLS, et la CertificateRequest initiale intervient pendant la poignée de main, avant la disponibilité des Application Data. Bien que des occasions ultérieures pour qu'un client TLS présente un certificat puissent exister, par ex. via la renégociation TLS 1.2 [RFC5246] ou l'authentification post-handshake TLS 1.3 [RFC8446], le présent document ne prévoit pas leur utilisation. Il est attendu qu'il soit courant qu'un serveur de ressources utilisant mutual TLS exige mutual TLS pour toutes les ressources qu'il héberge, ou qu'il serve les ressources protégées par mutual TLS et les ressources ordinaires sur des combinaisons distinctes de nom d'hôte et de port, bien que d'autres flux soient possibles. La synchronisation de la politique du serveur de ressources avec le serveur d'autorisation (AS) est hors du champ du présent document.
Dans le cadre d'un flux d'accès à une ressource protégée par mutual-TLS, le client effectue des requêtes vers la ressource protégée, comme décrit dans [RFC6750], toutefois ces requêtes DOIVENT être faites sur une connexion TLS mutuellement authentifiée en utilisant le même certificat que celui utilisé pour mutual TLS au point de terminaison de jeton.
La ressource protégée DOIT obtenir, auprès de sa couche d'implémentation TLS, le certificat client utilisé pour mutual TLS et DOIT vérifier que le certificat correspond au certificat associé au jeton d'accès. S'ils ne correspondent pas, la tentative d'accès à la ressource DOIT être rejetée avec une erreur, conformément à [RFC6750], en utilisant un code d'état HTTP 401 et le code d'erreur invalid_token.
Des métadonnées pour transmettre les capacités du serveur et du client concernant les jetons d'accès liés au certificat client mutual-TLS sont définies aux sections 3.3 et 3.4, respectivement.