OAuth 2.0: Avantages et cas d'utilisation - pourquoi?
Quelqu'un pourrait-il expliquer ce qui est bien avec OAuth2 et pourquoi nous devrions le mettre en œuvre? Je demande parce que je suis un peu confus à ce sujet - voici mes pensées actuelles:
Les requêtes OAuth1 (plus précisément HMAC) semblent logiques, faciles à comprendre, faciles à développer et vraiment, vraiment sécurisées.
OAuth2, à la place, apporte des demandes d'autorisation, des jetons d'accès et des jetons d'actualisation. Vous devez faire 3 demandes au tout début d'une session pour obtenir les données que vous recherchez. Et même dans ce cas, l’une de vos demandes finira par échouer à l’expiration du jeton.
Et pour obtenir un autre jeton d'accès, vous utilisez un jeton d'actualisation qui a été transmis en même temps que le jeton d'accès. Cela rend-il le jeton d'accès inutile du point de vue de la sécurité?
De plus, comme l'a récemment montré/r/netsec, le protocole SSL n'est pas entièrement sécurisé. Par conséquent, la fonctionnalité Push permettant de tout transférer sur TLS/SSL au lieu d'un protocole sécurisé HMAC m'embrouille.
OAuth affirme qu'il ne s'agit pas de sécurité à 100%, mais de le publier et de le terminer. Cela ne semble pas vraiment prometteur du point de vue d'un fournisseur. Je peux voir ce que le projet tente de réaliser lorsqu'il mentionne les 6 flux différents, mais cela ne correspond tout simplement pas à ma tête.
Je pense que ce serait peut-être plus ma difficulté à comprendre ses avantages et son raisonnement que de l'aimer vraiment, alors il peut s'agir d'une attaque injustifiée, et pardon si cela peut sembler être un coup de gueule.
Contexte: j'ai écrit des piles de clients et de serveurs pour OAuth 1.0a et 2.0.
OAuth 1.0a & 2.0 prennent en charge l'authentification à deux branches , dans laquelle un serveur est assuré de l'identité de l'utilisateur et authentification à trois branches , où un serveur est assuré par un fournisseur de contenu de l'identité de l'utilisateur. L'authentification à trois pieds est le lieu où les demandes d'autorisation et les jetons d'accès entrent en jeu, et il est important de noter que OAuth 1 en a aussi.
Le complexe: authentification à trois pattes
Un point essentiel de la spécification OAuth concerne un fournisseur de contenu (par exemple, Facebook, Twitter, etc.) afin de garantir un serveur (par exemple, une application Web souhaitant parler au fournisseur de contenu pour le compte du client) indiquant que le client possède une identité. L’authentification à trois branches offre la possibilité de le faire sans que le client ou le serveur ait besoin de connaître les détails de cette identité (par exemple, nom d’utilisateur et mot de passe).
Sans (?) Entrer trop dans les détails d'OAuth:
- Le client soumet une demande d'autorisation au serveur, qui confirme que le client est un client légitime de son service.
- Le serveur redirige le client vers le fournisseur de contenu afin de demander l'accès à ses ressources.
- Le fournisseur de contenu valide l'identité de l'utilisateur et lui demande souvent l'autorisation d'accéder aux ressources.
- Le fournisseur de contenu redirige le client vers le serveur, l'informant de son succès ou de son échec. Cette demande inclut un code d'autorisation en cas de succès.
- Le serveur envoie une requête hors bande au fournisseur de contenu et échange le code d'autorisation contre un jeton d'accès.
Le serveur peut désormais adresser des demandes au fournisseur de contenu pour le compte de l'utilisateur en transmettant le jeton d'accès.
Chaque échange (client-> serveur, serveur-> fournisseur de contenu) inclut la validation d'un secret partagé, mais étant donné que OAuth 1 peut s'exécuter sur une connexion non cryptée, chaque validation ne peut pas transmettre le secret par le fil.
Comme vous l'avez dit, c'est fait avec HMAC. Le client utilise le secret qu'il partage avec le serveur pour signer les arguments de sa demande d'autorisation. Le serveur prend les arguments, les signe lui-même avec la clé du client et peut voir s'il s'agit d'un client légitime (étape 1 ci-dessus).
Cette signature nécessite à la fois le client et le serveur de s’entendre sur l’ordre des arguments (ils signent donc exactement la même chaîne), et l’un des principaux griefs concernant OAuth 1 est qu’il nécessite à la fois la serveur et les clients à trier et signer à l'identique. C'est un code fastidieux et il est correct ou vous obtenez 401 Unauthorized avec peu d'aide. Cela augmente la barrière pour écrire un client.
En exigeant que la demande d'autorisation s'exécute sur SSL, OAuth 2.0 supprime le besoin de trier et de signer les arguments. Le client transmet son secret au serveur, qui le valide directement.
Les mêmes exigences sont présentes dans la connexion serveur-> fournisseur de contenu, et puisque c'est SSL qui élimine un obstacle à l'écriture d'un serveur qui accède aux services OAuth.
Cela facilite beaucoup les choses aux étapes 1, 2 et 5 ci-dessus.
Donc, à ce stade, notre serveur a un jeton d'accès permanent qui est un nom d'utilisateur/mot de passe équivalent à l'utilisateur. Il peut adresser des requêtes au fournisseur de contenu pour le compte de l'utilisateur en transmettant ce jeton d'accès à la requête (sous forme d'argument de requête, d'en-tête HTTP ou de données de formulaire POST).
Si le service de contenu est accessible uniquement via SSL, nous avons terminé. S'il est disponible via HTTP simple, nous aimerions protéger ce jeton d'accès permanent d'une manière ou d'une autre. Toute personne détectant la connexion serait en mesure d'accéder au contenu de l'utilisateur pour toujours.
La manière résolue dans OAuth 2 consiste à utiliser un jeton d'actualisation . Le jeton d'actualisation devient l'équivalent permanent du mot de passe, et il est uniquement transmis à l'aide de SSL . Lorsque le serveur a besoin d'accéder au service de contenu, il échange le jeton d'actualisation contre un jeton d'accès de courte durée. De cette façon, tous les accès HTTP détectables sont créés avec un jeton qui expirera. Google utilise une expiration de 5 minutes sur ses OAuth 2 API.
Ainsi, mis à part les jetons d'actualisation, OAuth 2 simplifie toutes les communications entre le client, le serveur et le fournisseur de contenu. Et les jetons d'actualisation existent uniquement pour assurer la sécurité lorsque le contenu est consulté sans chiffrement.
Authentification à deux pattes
Parfois, cependant, un serveur doit simplement contrôler l'accès à son propre contenu. L'authentification à deux branches permet au client d'authentifier l'utilisateur directement auprès du serveur.
OAuth 2 standardise certaines extensions de OAuth 1 largement utilisées. Celui que je connais le mieux a été introduit par Twitter sous le nom de xAuth . Vous pouvez le voir dans OAuth 2 sous la forme informations d'identification du mot de passe du propriétaire de la ressource .
Essentiellement, si vous pouvez faire confiance au client avec les informations d'identification de l'utilisateur (nom d'utilisateur et mot de passe), il peut les échanger directement avec le fournisseur de contenu contre un jeton d'accès. Cela rend OAuth beaucoup plus utile sur les applications mobiles: avec une authentification à trois pieds, vous devez incorporer une vue HTTP afin de gérer le processus d'autorisation avec le serveur de contenu.
Avec OAuth 1, cela ne faisait pas partie de la norme officielle et nécessitait la même procédure de signature que toutes les autres demandes.
Je viens d'implémenter le côté serveur de OAuth 2 avec les informations d'identification du mot de passe du propriétaire de la ressource et, du point de vue du client, obtenir le jeton d'accès est devenu simple: demander un jeton d'accès au serveur, en passant l'ID/secret du client comme un en-tête d'autorisation HTTP et le nom d'utilisateur/mot de passe de l'utilisateur en tant que données de formulaire.
Avantage: simplicité
Donc, du point de vue du réalisateur, les principaux avantages de OAuth 2 sont la complexité réduite. Il n’exige pas de procédure de signature de requête, ce qui n’est pas vraiment difficile mais qui est certes fastidieux. Cela réduit considérablement le travail requis pour agir en tant que client d'un service, et c'est là que (dans le monde moderne et mobile) vous souhaitez le plus réduire votre douleur. La complexité réduite du côté serveur-> fournisseur de contenu le rend plus évolutif dans le centre de données.
Et il codifie dans le standard certaines extensions de OAuth 1.0a (comme xAuth) qui sont maintenant largement utilisées.
Premièrement, comme indiqué clairement dans OAuth authentification
OAuth 2.0 n'est pas un protocole d'authentification.
L'authentification dans le contexte d'un utilisateur accédant à une application indique à une application qui est l'utilisateur actuel et si elle est présente ou non. Un protocole d'authentification complet vous indiquera probablement également un certain nombre d'attributs à propos de cet utilisateur, tels qu'un identifiant unique, une adresse électronique et le nom à appeler quand l'application dit "Good Morning".
Cependant, OAuth ne dit rien à l'application. OAuth ne dit absolument rien de l'utilisateur, ni comment il a prouvé sa présence, ni même s'il est toujours là. En ce qui concerne un client OAuth, il a demandé un jeton, obtenu un jeton et l'a finalement utilisé pour accéder à une API. Il ne sait pas qui a autorisé l'application ni même s'il y avait même un utilisateur.
Il existe une norme pour l'authentification des utilisateurs à l'aide d'OAuth: OpenID Connect, compatible avec OAuth2.
Le jeton OpenID Connect ID est un jeton Web JSON (JWT) signé qui est attribué à l’application client à côté du jeton d’accès OAuth habituel. Le jeton d'identification contient un ensemble de revendications concernant la session d'authentification, y compris un identifiant pour l'utilisateur (sous-traitant), l'identifiant pour le fournisseur d'identité qui a émis le jeton (iss) et l'identifiant du client pour lequel ce jeton a été créé ( aud).
Dans Go, vous pouvez consulter coreos/dex, un fournisseur OpenID Connect Identity (OIDC) et OAuth 2.0 avec un connecteur enfichable.
Réponse de cet article vonc
Je répondrais à cette question légèrement différemment, et je serai très précis et bref, principalement parce que @Peter T a répondu à toutes les questions.
Le principal avantage de cette norme est de respecter deux principes:
- Séparation des préoccupations.
- Découpler l'authentification de l'application Web, qui sert généralement les entreprises.
En faisant cela,
- Vous pouvez implémenter une alternative à Single SignOn: Si vous avez plusieurs applications qui font confiance à un STS. Ce que je veux dire, un nom d'utilisateur pour toutes les applications.
- Vous pouvez activer votre application Web (le client) pour accéder à des ressources appartenant à l'utilisateur et n'appartenant pas à l'application Web (le client).
- Vous pouvez confier le processus d'authentification à un tiers en qui vous avez confiance, sans vous soucier de la validation de l'authenticité de l'utilisateur.