5. Considérations de sécurité

Puisque les demandes au point de terminaison d'enregistrement de client entraînent la transmission d'identifiants en texte clair (dans la demande et la réponse HTTP), le serveur d'autorisation DOIT exiger l'utilisation d'un mécanisme de sécurité de la couche transport lors de l'envoi de demandes au point de terminaison d'enregistrement. Le serveur DOIT prendre en charge TLS 1.2 [RFC5246] et PEUT prendre en charge des mécanismes de sécurité de la couche transport supplémentaires répondant à ses exigences de sécurité. Lors de l'utilisation de TLS, le client DOIT effectuer une vérification de certificat de serveur TLS/SSL, conformément à la RFC 6125 [RFC6125]. Les considérations de sécurité de mise en œuvre peuvent être trouvées dans les recommandations pour l'utilisation sécurisée de TLS et DTLS [BCP195].

Pour les clients qui utilisent des types d'octroi basés sur la redirection tels que "authorization_code" et "implicit", les serveurs d'autorisation DOIVENT exiger des clients qu'ils enregistrent leurs valeurs d'URI de redirection. Cela peut aider à atténuer les attaques où des acteurs malveillants injectent et usurpent l'identité d'un client valablement enregistré et interceptent son code d'autorisation ou ses jetons via un URI de redirection invalide ou un redirecteur ouvert. De plus, afin d'empêcher le détournement des valeurs de retour de la redirection, les valeurs d'URI de redirection enregistrées DOIVENT être l'une des suivantes :

Un site Web distant protégé par TLS (par exemple, https://client.example.com/oauth_redirect)
Un site Web hébergé sur la machine locale utilisant un URI HTTP (par exemple, http://localhost:8080/oauth_redirect)
Une URL non-HTTP spécifique à l'application qui est disponible uniquement pour l'application cliente (par exemple, exampleapp://oauth_redirect)

Les clients publics PEUVENT s'enregistrer auprès d'un serveur d'autorisation utilisant ce protocole, si la politique du serveur d'autorisation le leur permet. Les clients publics utilisent une valeur "none" pour le champ de métadonnées "token_endpoint_auth_method" et sont généralement utilisés avec le type d'octroi "implicit". Souvent, ces clients seront des applications intégrées au navigateur de courte durée demandant l'accès aux ressources d'un utilisateur et l'accès est lié à la session active d'un utilisateur sur le serveur d'autorisation. Étant donné que ces clients n'ont souvent pas de stockage à long terme, il est possible que ces clients aient besoin de se réenregistrer à chaque chargement de l'application du navigateur. Pour éviter la prolifération résultante d'identifiants de client morts, un serveur d'autorisation PEUT décider d'expirer les enregistrements pour les clients existants répondant à certains critères après qu'une période de temps se soit écoulée. Alternativement, ces clients pourraient être enregistrés sur le serveur à partir duquel le code de l'application intégrée au navigateur est servi, et la configuration du client pourrait être poussée vers le navigateur aux côtés du code.

Étant donné que différents types d'octroi OAuth 2.0 ont des propriétés de sécurité et d'utilisation différentes, un serveur d'autorisation PEUT exiger des enregistrements séparés pour un logiciel afin de prendre en charge plusieurs types d'octroi. Par exemple, un serveur d'autorisation pourrait exiger que tous les clients utilisant le type d'octroi "authorization_code" utilisent un secret client pour la "token_endpoint_auth_method" mais que tous les clients utilisant le type d'octroi "implicit" n'utilisent aucune authentification au point de terminaison de jeton. Dans une telle situation, un serveur PEUT interdire aux clients de s'enregistrer pour les types d'octroi "authorization_code" et "implicit" simultanément. De même, le type d'octroi "authorization_code" est utilisé pour représenter un accès au nom d'un utilisateur final, mais le type d'octroi "client_credentials" représente un accès au nom du client lui-même. Pour des raisons de sécurité, un serveur d'autorisation pourrait exiger que différentes portées soient utilisées pour ces différents cas d'utilisation, et, par conséquent, il PEUT interdire à ces deux types d'octroi d'être enregistrés ensemble par le même client. Dans tous ces cas, le serveur d'autorisation répondrait par une réponse d'erreur "invalid_client_metadata".

À moins qu'elles ne soient utilisées comme revendication dans une déclaration logicielle, le serveur d'autorisation DOIT traiter toutes les métadonnées de client comme auto-déclarées. Par exemple, un client malveillant pourrait utiliser le nom et le logo d'un client légitime dont il tente d'usurper l'identité. De plus, un client malveillant pourrait essayer d'utiliser l'identifiant logiciel ou la version logicielle d'un client légitime pour tenter de s'associer sur le serveur d'autorisation avec des instances du client légitime. Pour contrer cela, un serveur d'autorisation DOIT prendre des mesures appropriées pour atténuer ce risque en examinant l'ensemble de la demande d'enregistrement et de la configuration du client. Par exemple, un serveur d'autorisation pourrait émettre un avertissement si le domaine/site du logo ne correspond pas au domaine/site des URI de redirection. Un serveur d'autorisation pourrait également refuser des demandes d'enregistrement d'un identifiant logiciel connu qui demande des URI de redirection différents ou un URI client différent. Un serveur d'autorisation peut également présenter des messages d'avertissement aux utilisateurs finaux concernant les clients enregistrés dynamiquement dans tous les cas, en particulier si ces clients ont été récemment enregistrés ou n'ont été approuvés par aucun utilisateur sur le serveur d'autorisation auparavant.

Dans une situation où le serveur d'autorisation prend en charge l'enregistrement ouvert des clients, il doit être extrêmement prudent avec toute URL fournie par le client qui sera affichée à l'utilisateur (par exemple, "logo_uri", "tos_uri", "client_uri", et "policy_uri"). Par exemple, un client malveillant pourrait spécifier une demande d'enregistrement avec une référence à un téléchargement furtif dans la "policy_uri", incitant l'utilisateur à cliquer dessus pendant l'autorisation. Le serveur d'autorisation DEVRAIT vérifier si les "logo_uri", "tos_uri", "client_uri", et "policy_uri" ont le même hôte et le même schéma que ceux définis dans le tableau des "redirect_uris" et que tous ces URI se résolvent en pages Web valides. Puisque ces valeurs d'URI qui sont destinées à être affichées à l'utilisateur sur la page d'autorisation, le serveur d'autorisation DEVRAIT protéger l'utilisateur du contenu malveillant hébergé aux URL lorsque cela est possible. Par exemple, avant de présenter les URL à l'utilisateur sur la page d'autorisation, le serveur d'autorisation pourrait télécharger le contenu hébergé aux URL, vérifier le contenu par rapport à un scanner de logiciels malveillants et un filtre de liste noire, déterminer s'il y a ou non un contenu sécurisé et non sécurisé mixte à l'URL, et d'autres mesures d'atténuation côté serveur possibles. Notez que le contenu de ces URL peut changer à tout moment et le serveur d'autorisation ne peut pas fournir une confiance complète dans la sécurité des URL, mais ces pratiques pourraient aider. Pour atténuer davantage ce type de menace, le serveur d'autorisation peut également avertir l'utilisateur que les liens URL ont été fournis par un tiers, devraient être traités avec prudence, et ne sont pas hébergés par le serveur d'autorisation lui-même. Par exemple, au lieu de fournir les liens directement dans une ancre HTML, le serveur d'autorisation peut diriger l'utilisateur vers une page d'avertissement interstitielle avant de permettre à l'utilisateur de continuer vers l'URL cible.

Les clients PEUVENT utiliser à la fois l'objet JSON direct et la déclaration logicielle encodée en JWT pour présenter les métadonnées client au serveur d'autorisation dans le cadre de la demande d'enregistrement. Une déclaration logicielle est protégée cryptographiquement et représente des revendications faites par l'émetteur de la déclaration, tandis que l'objet JSON représente les revendications auto-déclarées faites par le client ou le développeur directement. Si la déclaration logicielle est valide et signée par une autorité acceptable (telle que l'éditeur de l'API logicielle), les valeurs des métadonnées client au sein de la déclaration logicielle DOIVENT prévaloir sur les valeurs de métadonnées présentées dans l'objet JSON simple, qui auraient pu être interceptées et modifiées.

Comme toutes les valeurs de métadonnées, la déclaration logicielle est un élément qui est auto-déclaré par le client, même si son contenu a été signé numériquement ou MACé par l'émetteur de la déclaration logicielle. En tant que tel, la présentation de la déclaration logicielle n'est pas suffisante dans la plupart des cas pour identifier complètement un logiciel client. Un jeton d'accès initial, en revanche, ne contient pas nécessairement d'informations sur un logiciel client particulier mais représente plutôt l'autorisation d'utiliser le point de terminaison d'enregistrement. Un serveur d'autorisation DOIT considérer la demande d'enregistrement complète, y compris la déclaration logicielle, le jeton d'accès initial, et les valeurs de métadonnées client JSON, lors de la décision d'honorer ou non une demande d'enregistrement donnée.

Si un serveur d'autorisation reçoit une demande d'enregistrement pour un client qui n'est pas destiné à avoir plusieurs instances enregistrées simultanément et que le serveur d'autorisation peut déduire une duplication d'enregistrement (par exemple, il utilise les mêmes valeurs "software_id" et "software_version" qu'un autre client existant), le serveur DEVRAIT traiter le nouvel enregistrement comme étant suspect et rejeter l'enregistrement. Il est possible que le nouveau client essaie d'usurper l'identité du client existant afin de tromper les utilisateurs pour qu'ils l'autorisent, ou que l'enregistrement original ne soit plus valide. Les détails de la gestion de cette situation sont spécifiques au déploiement du serveur d'autorisation et hors du champ d'application de cette spécification.

Puisqu'un identifiant client est une valeur publique qui peut être utilisée pour usurper l'identité d'un client au point de terminaison d'autorisation, un serveur d'autorisation qui décide d'émettre le même identifiant client à plusieurs instances d'un client enregistré doit être très particulier sur les circonstances dans lesquelles cela se produit. Par exemple, le serveur d'autorisation peut limiter un identifiant client donné aux clients utilisant le même flux basé sur la redirection et les mêmes URI de redirection. Un serveur d'autorisation NE DEVRAIT PAS émettre le même secret client à plusieurs instances d'un client enregistré, même s'ils reçoivent le même identifiant client, sinon le secret client pourrait être divulgué, permettant à des imposteurs malveillants d'usurper l'identité d'un client confidentiel.