OAuth2 ROPC vs Basic Auth pour public REST APIs?
Le cas d'utilisation spécifique qui m'intéresse ici est l'authentification des clients REST contre des points de terminaison de serveur accessibles au public (comme une API publique REST)).
La solution la plus simple ici est Authentification de base . Mais j'entends souvent OAuth2 présenté comme une solution d'authentification supérieure dans presque toutes les circonstances.
Le problème est que le type d'octroi seulement OAuth2 est faisable pour un client REST authentification par rapport à un serveur REST est - Informations d'identification du mot de passe du propriétaire de la ressource (ROPC) , car les subventions de code et les subventions implicites nécessitent une interface utilisateur/page Web (hébergée par le serveur Auth) pour que l'utilisateur se connecte et autorise manuellement l'application cliente.
Le fonctionnement du ROPC est, en envoyant le nom d'utilisateur/mot de passe du propriétaire de la ressource, et l'ID client sous la forme paramètres de chaîne de requête?!? C'est encore moins sécurisé (à mon humble avis) que l'authentification de base, qui au moins base-64 code les informations d'identification et les envoie à l'intérieur d'un en-tête qui peut être chiffré par TLS!
Je demande donc: dans le contexte des API publiques REST, OAuth2 ROPC vraiment mieux que Basic Auth? Quoi de plus sécurisé que le ROPC OAuth2?
Mise à jour
Je viens de lire cet excellent article qui explique la sécurité d'Amazon non basée sur OAuth2 REST sécurité pour AWS. Il s'agit essentiellement d'une solution basée sur une clé privée où les hachages de chaque REST est générée et envoyée en tant que side-car à côté de la demande normale (non chiffrée). Seuls le client et le serveur connaissent la clé privée, donc lorsque le serveur reçoit la demande (à nouveau, contenant la normale demande + la demande hachée), le serveur recherche la clé privée du client, applique le même hachage à la demande normale, puis compare les deux hachages.
Cela semble beaucoup plus compliqué, complexe et sécurisé que le ROPC d'OAuth2! À moins que quelque chose me manque major ici, OAuth2 ROPC envoie simplement client_id, username et password en tant que paramètres de chaîne de requête ... totalement et totalement non sécurisés! Cette solution basée sur HMAC/hachée semble être beaucoup plus impressionnante et sécurisée.
Le fait est que même l'auteur de cet article poursuit:
Vous [réaliserez] lentement et accepterez aussi qu'à un moment donné, vous devrez implémenter OAuth ...
Ba-ba-bwhat?!?! Si OAuth2 est moins sécurisé que cette solution intelligente basée sur HMAC/hash , pourquoi l'auteur de cet article pense-t-il que OAuth doit être adopté à un moment donné. Je suis tellement confus.
La réponse à votre question peut être au niveau du code, du protocole ou de l'architecture. Je vais essayer de résumer ici la plupart des problèmes au niveau du protocole, car cela est généralement critique dans l'analyse des avantages et des inconvénients. Gardez à l'esprit que OAuth2 est beaucoup plus que Informations d'identification du mot de passe du propriétaire de la ressource qui, selon la spécification, existe pour des "raisons d'héritage ou de migration", est considéré comme "à plus haut risque que les autres types de droits "et la spécification stipule explicitement que les clients et les serveurs d'autorisation" DEVRAIENT minimiser l'utilisation de ce type de droits et utiliser d'autres types de droits dans la mesure du possible ".
Il y a encore de nombreux avantages à utiliser ROPC par rapport à l'authentification de base, mais avant d'entrer dans le détail, comprenons la différence de protocole de base entre OAuth2 et l'authentification de base. S'il vous plaît, restez avec moi pendant que j'explique cela et je reviendrai au ROPC plus tard.
Flux d'authentification utilisateur
Il existe quatre rôles définis dans la spécification OAuth2. Avec des exemples, ce sont:
- Propriétaire de la ressource: l'utilisateur qui a accès à une ressource, par exemple dans votre cas, différents utilisateurs peuvent avoir un niveau d'accès différent à l'API REST;
- Le client: généralement l'application que l'utilisateur utilise et a besoin d'accéder à la ressource pour fournir des services à l'utilisateur;
- Serveur de ressources: l'API REST dans votre cas; et
- Serveur d'autorisation: le serveur auquel les informations d'identification de l'utilisateur sont présentées et qui authentifiera l'utilisateur.
Lorsqu'une application cliente s'exécute, elle se voit accorder l'accès aux ressources en fonction de l'utilisateur. Si un utilisateur dispose de privilèges d'administrateur, les ressources et opérations disponibles pour l'utilisateur dans REST API peuvent être bien plus qu'un utilisateur sans privilèges d'administrateur.
OAuth2 offre également la possibilité d'utiliser un seul serveur d'autorisation avec plusieurs clients et pour plusieurs ressources. À titre d'exemple, un serveur de ressources peut accepter l'authentification de l'utilisateur avec Facebook (qui peut agir comme serveur d'autorisation dans un tel cas). Ainsi, lorsque l'utilisateur exécute une application (c'est-à-dire le client), il envoie l'utilisateur à Facebook. L'utilisateur saisit ses informations d'identification dans Facebook et le client récupère un "jeton" qu'il peut présenter au serveur de ressources. Le serveur de ressources examine le jeton et l'accepte après avoir vérifié que Facebook l'a effectivement émis et autorise l'utilisateur à accéder à la ressource. Dans ce cas, le client ne voit jamais les informations d'identification de l'utilisateur (c'est-à-dire leurs informations d'identification Facebook).
Mais disons que vous gérez les identités de vos utilisateurs (et que vous avez un serveur d'autorisation) au lieu de Facebook, qui accorde déjà des jetons à votre client. Supposons maintenant que vous ayez également un partenaire et que vous souhaitiez autoriser son application (c'est-à-dire son client) à accéder à votre REST API. Avec l'authentification de base (ou même ROPC), l'utilisateur fournira des informations d'identification à ce client qui l'enverra au serveur d'autorisation. Le serveur d'autorisation fournira alors un jeton qui peut être utilisé par le client pour accéder aux ressources. Malheureusement, cela signifie que les informations d'identification de l'utilisateur sont désormais visibles pour ce client également. vous voulez que l'application d'un partenaire (qui pourrait être externe à votre organisation) connaisse même le mot de passe d'un utilisateur. C'est un problème de sécurité maintenant. Pour atteindre cet objectif, vous souhaitez utiliser un autre flux (tel que l'octroi du code d'autorisation) dans lequel l'utilisateur fournit directement les informations d'identification au serveur d'autorisation.
Ainsi, avec OAuth2, l'idéal serait de ne pas utiliser ROPC dans de tels cas plutôt d'utiliser un autre, comme le flux de code d'autorisation. Cela protège toute application de connaître les informations d'identification de l'utilisateur qui ne sont présentées qu'au serveur d'autorisation. Ainsi, les informations d'identification d'un utilisateur ne sont pas divulguées. Les mêmes problèmes s'appliquent à l'authentification de base, mais dans la section suivante, j'expliquerai comment ROPC est encore meilleur car les informations d'identification de l'utilisateur n'ont toujours pas besoin d'être stockées par le client dans ROPC pour un accès persistant par les clients.
Notez que lorsque l'utilisateur accède au serveur d'autorisation, le serveur d'autorisation peut également demander à l'utilisateur de confirmer qu'il souhaite autoriser le client à accéder aux ressources en son nom ou non. C'est pourquoi il est appelé serveur d'autorisation car le processus d'autorisation d'un client pour accéder aux ressources est impliqué dans le processus. Si l'utilisateur n'autorise pas le client, il n'aura pas accès aux ressources. De même, si l'utilisateur lui-même n'a pas accès aux ressources, le serveur d'autorisation peut toujours refuser l'accès et ne pas émettre de jeton.
Dans l'authentification de base, même le serveur d'autorisation et le serveur de ressources sont combinés en une seule entité. Ainsi, le serveur de ressources veut autoriser l'utilisateur, demande donc les informations d'identification du client. Le client fournit les informations d'identification utilisées par le serveur de ressources pour authentifier l'utilisateur. Cela signifie que plusieurs serveurs de ressources exigeront essentiellement des informations d'identification de l'utilisateur.
Émission de jetons
Les clients obtiennent des jetons du serveur d'autorisation, les conservent et les utilisent pour accéder aux ressources (plus de détails sur les jetons eux-mêmes ci-dessous). Les clients ne connaissent jamais le mot de passe de l'utilisateur (dans des flux autres que ROPC) et n'ont pas besoin de le stocker. Dans ROPC, même si les clients connaissent le mot de passe de l'utilisateur, ils n'ont toujours pas besoin de le stocker car ils utilisent ces jetons pour accéder aux ressources. En revanche, dans l'authentification de base, si un client ne veut pas que l'utilisateur fournisse des informations d'identification à chaque session, le client doit stocker le mot de passe de l'utilisateur afin de pouvoir le fournir la prochaine fois. C'est un inconvénient majeur de l'utilisation de l'authentification de base, sauf si le client n'est qu'une application Web, auquel cas les cookies peuvent répondre à certaines de ces préoccupations. Avec les applications natives, ce n'est généralement pas une option.
Il y a un autre aspect d'OAuth2 qui est impliqué dans la façon dont les jetons sont émis et fonctionnent. Lorsqu'un utilisateur fournit des informations d'identification au serveur d'autorisation (même dans ROPC), le serveur d'autorisation peut attribuer un ou plusieurs des deux types de jetons: 1) jeton d'accès et 2) jeton d'actualisation.
Les jetons d'accès sont envoyés au serveur de ressources qui accordera l'accès aux ressources après sa validation, et ils ont généralement une courte durée de vie, par exemple 1h. Les jetons d'actualisation sont envoyés au serveur d'autorisation par le client pour obtenir un autre jeton d'accès à son expiration, et ont généralement une longue durée de vie (par exemple, de quelques jours à plusieurs mois, voire plusieurs années).
Lorsque le client fournit le jeton d'accès au serveur de ressources, il regarde le jeton et après validation, regarde à l'intérieur du jeton pour déterminer s'il autorise l'accès ou non. Tant que le jeton d'accès est valide, le client peut continuer à l'utiliser. Supposons que l'utilisateur ferme l'application et la démarre le lendemain, et le jeton d'accès a expiré. Le client va maintenant appeler le serveur d'autorisation et présenter le jeton d'actualisation en supposant qu'il n'est pas expiré. Le serveur d'autorisation, puisqu'il a déjà émis le jeton, le vérifie et peut déterminer que l'utilisateur n'a pas besoin de fournir à nouveau les informations d'identification et donne ainsi un autre jeton d'accès au client. Le client a à nouveau accès au serveur de ressources. C'est ainsi que les applications clientes pour Facebook et Twitter demandent généralement des informations d'identification une fois, puis ne demandent pas à l'utilisateur de fournir à nouveau les informations d'identification. Ces applications n'ont jamais besoin de connaître les informations d'identification des utilisateurs et peuvent néanmoins accéder aux ressources chaque fois que l'utilisateur démarre l'application.
L'utilisateur peut maintenant accéder au serveur d'autorisation (par exemple dans son profil d'utilisateur Facebook), changer de mot de passe sans impact sur les applications clientes. Ils continueront tous à fonctionner correctement. Si l'utilisateur perd un appareil sur lequel il avait déjà une application avec des jetons d'actualisation, il peut demander au serveur d'autorisation (par exemple Facebook) de "se déconnecter" des applications que le serveur d'autorisation (par exemple Facebook) accomplira en n'honorant aucune actualiser les jetons et forcer l'utilisateur à fournir à nouveau ses informations d'identification lorsqu'il essaie d'accéder aux ressources via ces applications.
JWT est simplement le format de jeton généralement utilisé avec OAuth2 et OpenID Connect. Les méthodes de signature et de validation du jeton sont également standardisées avec des bibliothèques disponibles pour ceux-ci au lieu que chaque serveur de ressources implémente une autre solution. Ainsi, l'avantage réside dans la réutilisabilité du code qui a été vérifié et continue d'être pris en charge.
Implications de sécurité
L'authentification de base sera plus faible lorsque l'un des scénarios ci-dessus apparaît dans l'image. Il existe également un vaste modèle de menace pour OAuth2 disponible pour les développeurs qui peuvent utiliser les suggestions qu'il contient pour éviter les vulnérabilités courantes dans leurs implémentations. Si vous passez par le modèle de menace, vous verrez que de nombreuses vulnérabilités liées à l'implémentation (telles que le redirecteur ouvert et CSRF) y sont également couvertes. Je ne suis pas passé par la comparaison de ceux contre l'authentification de base dans cette réponse.
Le dernier avantage majeur d'OAuth2 est que le protocole est standardisé et que plusieurs serveurs d'autorisation, clients et serveurs de ressources l'honorent. De nombreuses bibliothèques sont disponibles pour les développeurs, qui sont maintenues afin que des problèmes de sécurité soient trouvés dans les implémentations, les bibliothèques sont mises à jour tout en permettant l'interopérabilité.
Conclusion
Si vous écrivez une nouvelle application, IMO, le cas idéal serait d'éviter à la fois l'authentification de base et le ROPC en raison des problèmes inhérents à celles-ci. Cependant, chaque application a des besoins, des délais, des compétences de développeur, etc. différents, donc la décision est prise au cas par cas. Mais même si vous n'aviez pas plus besoin que l'authentification de base, en la choisissant, vous pourriez vous enfermer dans une architecture qui ne serait pas facile à étendre (par exemple, si vous avez plusieurs serveurs à l'avenir, vous ne voudriez pas nécessairement avoir l'utilisateur fournit des informations d'identification à chacun d'eux plutôt qu'il suffit de fournir une fois au serveur d'autorisation, qui peut distribuer des jetons, etc.)
Notez que je n'ai pas répondu à votre commentaire sur la façon dont les informations d'identification sont envoyées par câble, car elles peuvent être sécurisées à l'aide de TLS ou d'un protocole similaire, ou d'une preuve de possession, etc. Comme quelqu'un l'a déjà suggéré, le codage en base 64 est 0 sécurité, veuillez ne pas être trompé par cela. Les différences mentionnées ci-dessus sont généralement au niveau architectural et c'est donc là que je me suis concentré car l'architecture est la plus difficile à changer une fois mise en œuvre.
Azure Active Directory B2C Basic , un service sur lequel je travaille et qui a récemment été publié en avant-première publique, permet à une application tierce d'utiliser AAD comme serveur d'autorisation avec interopérabilité avec les IDP sociaux (tels que Facebook, Google, etc.). Il permet également aux utilisateurs de créer leurs propres comptes au lieu d'utiliser des PDI sociaux et ceux-ci peuvent ensuite être utilisés à des fins d'authentification. Il existe également quelques autres services comme celui-ci (par exemple, un autre que je connais est auth ) qui peut être utilisé par les développeurs pour externaliser complètement l'authentification et la gestion des utilisateurs pour leurs applications et ressources. Les mêmes caractéristiques de protocoles que j'ai mentionnées ci-dessus sont utilisées par les développeurs pour découpler le serveur d'autorisation (AAD), une ressource (par exemple leurs REST), le client (par exemple leurs applications mobiles) et les utilisateurs. J'espère que cette explication aide un peu.
L'authentification de base n'est pas un bon moyen de sécuriser votre REST. J'ai expliqué les raisons pour lesquelles dans cette réponse .
Lorsque vous créez une API REST, vous implémentez serveur de ressources en termes OAuth2. Tout ce que votre API doit faire est de valider que le jeton a été transmis avec la demande dans le en-tête HTTP d'autorisation est valide et d'un émetteur de confiance. Voir ce lien pour les étapes comment implémenter la validation s'il n'y a pas de bibliothèque disponible.
La façon dont votre le client acquiert le jeton du serveur d'autorisation dépend de ce que type de client c'est. N'oubliez pas que vous devez spécifier le type de client que vous allez utiliser lorsque vous enregistrez le client auprès du serveur d'autorisation.
Dans le cas d'une application Web parlant à votre serveur, elle pourrait utiliser octroi de code d'autorisation . S'il s'agit d'un client non fiable comme une application mobile ou une application JavaScript, il doit utiliser le octroi implicite .
Pour les services principaux qui ne peuvent pas interagir avec un propriétaire de ressource, vous pouvez utiliser octroi des informations d'identification client . Pour les outils de ligne de commande, vous pouvez utiliser les informations d'identification du client ou octroi de mot de passe du propriétaire de la ressource .
Tout dépend du type de client que vous utilisez.
Enfin, la validation d'un jeton JWT se produit sur le serveur de ressources sans avoir à parler au serveur d'autorisation. Cela conduit à une meilleure architecture évolutive, puis des solutions qui doivent rechercher des données privées pour chaque client.
Je pense que vous êtes mal informé sur le chiffrement des variables GET dans une URL
Les seules personnes qui peuvent afficher les variables GET dans une demande sont l'ordinateur d'origine et le serveur de réception ( link ).
Seule la recherche DNS basée sur le domaine auquel la demande HTTPS est envoyée n'est pas chiffrée. Tout le reste, les ports, les variables GET, l'ID de ressource, est crypté.
La seule mise en garde à ce sujet est que le serveur de réception peut se déconnecter du chemin de demande complet, mais vous en avez le contrôle afin que vous puissiez protéger ces données comme bon vous semble.
C'est sécurisé ou pas sécurisé. Ni plus ni moins. Avoir base64 ne rend pas l'authentification de base (ou quoi que ce soit) plus sûr.
Il n'y a rien de mal à envoyer quoi que ce soit non crypté s'il utilise un canal crypté comme Https.
OAuth has plus de fonctionnalités, utilisez-le si vous en avez besoin. Pour toute autre chose, par exemple bancaire, en utilisant le défi-réponse de base est bien et sécurisé.
Je pense que vous devez d'abord comprendre les terminologies. Vous comparez - Autorisation et Signature numérique
OAuth est un standard ouvert pour Autorisation , où comme ce que fait Amazon (selon l'article et les détails fournis dans votre question) crée une signature numérique valide qui donne à un destinataire (ici Amazon) des raisons de croire que le message a été créé par un expéditeur connu, que l'expéditeur ne peut pas nier avoir envoyé le message ( authentification et non-répudiation)
Pour quel mécanisme d'autorisation utiliser, cela dépend plus ou moins de votre cas d'utilisation.
Vous trouverez ci-dessous ce qui se trouve sur StackOverflow ici :
Authentification de base qui nécessite un hachage très simple pour calculer le seul en-tête requis - OAuth est sans aucun doute une authentification plus coûteuse. La chose importante à réaliser est que les deux mécanismes d'authentification servent entièrement différents L'authentification de base sert à authentifier un client auprès d'une application principale. OAuth est destiné à autoriser un tiers à accéder aux données client à partir d'une application principale. Les deux ont leur place et les sélectionnent l'une sur l'autre. être guidé par le cas d'utilisation particulier de la mise en œuvre.
Et voici un autre article intéressant comparant les deux.
L'authentification de base sur SSL est en fait assez responsable, d'un point de vue de sécurité simpliste. Lorsque nous sommes confrontés à des noms d'utilisateur et des mots de passe, l'authentification de base est une solution courante car elle est si facile à mettre en œuvre. La transmission des informations d'identification est cryptée via SSL et l'utilisation de l'en-tête "Authorization" est omniprésente dans les clients et les systèmes HTTP.