OAuth2 et authentification
Je vois beaucoup de confusion sur OAuth2 et l'authentification, j'ai donc créé cette question dans l'espoir de dissiper une partie de la confusion. Parlons donc des points suivants:
- Quelle est la différence entre l'authentification et l'autorisation?
- Que doit faire OAuth2?
- Pourquoi le flux implicite OAuth2 n'est-il pas sécurisé pour l'authentification tout en étant sécurisé pour l'autorisation? (Astuce: les jetons d'accès ne sont pas liés à un client spécifique)
- Quelle est la différence entre le flux implicite OAuth2 et le flux de code d'authentification Oauth2 et quand les utiliser?
- Le flux de code d'authentification OAuth2 fonctionne-t-il pour l'authentification?
- Devriez-vous utiliser OpenID au lieu d'OAuth2 pour l'authentification?
- Pourquoi Google dit-il que leur infrastructure "OAuth2" peut être utilisée à la fois pour l'authentification et l'autorisation.
Les API Google utilisent le protocole OAuth 2.0 pour l'authentification et l'autorisation.
https://developers.google.com/identity/protocols/OAuth2
Spécification OAuth2: https://tools.ietf.org/html/rfc6749
1.What is the difference between authentication and authorization?
L'authentification est le processus par lequel un serveur vérifie si un utilisateur est bien l'utilisateur qu'il prétend être. Cela se fait généralement, lorsque l'utilisateur donne le nom d'utilisateur et un mot de passe, tandis que le serveur vérifie ces informations d'identification (nom d'utilisateur, mot de passe) avec celles stockées dans sa base de données, lorsque le premier utilisateur a créé son compte. L'autorisation est lorsqu'une entité autorise une autre entité à effectuer une action. Dans ce cas, par exemple, c'est lorsqu'un site souhaite accéder aux données d'un utilisateur, qui sont stockées et détenues sur un autre site Web.
2.What is OAuth2 meant to do?
Officiellement, OAuth2 autorise un utilisateur à autoriser un site Web client C à accéder à ses données à partir d'un site Web de serveur de ressources RS après authentification via un site Web de serveur d'authentification AS. Cela semble assez complexe, donc pour simplifier, un exemple courant est lorsqu'un utilisateur se connecte à un site Web en utilisant son compte Facebook. Dans ce cas, le site Web client et le site Web du serveur de ressources sont identiques (C = RS = le site Web visité) et le serveur d'authentification est Facebook (AS = Facebook). A noter que celui-ci a été créé, afin que les C, RS n'apprennent pas le mot de passe de l'utilisateur, tout en pouvant s'authentifier. 
3.Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?
La spécificité du flux implicite est le fait que le jeton d'accès est donné à l'agent utilisateur pour être transmis à l'application. Ainsi, il est uniquement basé sur l'URI de redirection. Ainsi, ce flux n'authentifie pas l'identité de l'application, car il n'y a pas de confidentialité secrète client (jeton d'accès exposé à l'utilisateur et aux applications s'exécutant sur mobile)
4.What is the difference between OAuth2 implicit flow and Oauth2 authentication code flow and when to use which?
Comme décrit précédemment, dans le flux implicite, le jeton d'accès est transmis à l'application par l'agent utilisateur. D'autre part, dans le flux de code d'autorisation, le serveur Web client obtient d'abord un code d'autorisation (après que le propriétaire/l'utilisateur de la ressource a donné l'accès), puis passe un appel à l'API en passant (clientID, secretID) avec le code d'autorisation pour obtenir le jeton d'accès. Ceci est fait, de sorte qu'en cas de connexions HTTP (pas de cryptage SSL), le jeton d'accès n'est pas accessible à l'homme du milieu (routeurs, mandataires, etc.). Ainsi, le premier convient aux applications mobiles, tandis que le dernier convient aux applications côté serveur.
5.Does OAuth2 authentication code flow work for authentication?
Oui, le flux de code d'autorisation authentifie également l'utilisateur via le serveur d'authentification.
6.Should you use OpenID instead of OAuth2 for authentication?
Oui.
OpenID est utilisé pour l'authentification. Un exemple est lorsque nous souhaitons que les utilisateurs puissent se connecter à plusieurs sites Web avec un seul ensemble d'informations d'identification (authentification par connexion).
OAuth est utilisé pour l'autorisation, comme décrit précédemment. Notez que OAuth peut être légèrement ajusté (comme dans l'exemple précédent, où C = RS) afin d'effectuer une (pseudo-) authentification, via autorisation. Mais, si nous voulons seulement l'authentification, nous peut utiliser OpenID.
7.Why is google saying that their "OAuth2" framework can be used for both authentication and authorization.
Je suppose que les vraies raisons de cette décision de conception ne peuvent être données que par les ingénieurs Google correspondants, mais je pourrais supposer qu'au lieu d'utiliser à la fois OpenID et OAuth, ils ont choisi d'utiliser un seul protocole pour les deux utilisations, afin de simplifier les choses. Cependant, sachez que l'authentification via OAuth se fait en authentifiant quelqu'un, à travers les données qu'il possède. Un exemple terne serait que lorsque j'essaie d'entrer dans le bâtiment de mon travail , Je ne suis pas interrogé sur mes informations d'identification, car ma carte d'employé est évidemment dans mon cou. C'est ainsi que l'authentification se fait via OAuth, assez simplifiée. Donc, vous pouvez voir que cela peut faire plusieurs hypothèses qui ne tiennent pas toujours sous chaque Et c'est la raison pour laquelle il est généralement recommandé d'utiliser OAuth uniquement pour l'autorisation et utiliser OpenID, si vous devez également implémenter l'authentification.
Un joli lien décrivant les différents flux de OAuth pour référence
@RaptisDimos a donné une bonne réponse mais je pense que je vais m'étendre sur le point # 3.
- Pourquoi le flux implicite OAuth2 n'est-il pas sécurisé pour l'authentification tout en étant sécurisé pour l'autorisation?
Le problème avec le flux implicite lorsque vous essayez de l'utiliser pour l'authentification est que le client reçoit directement un jeton d'accès et que ce jeton d'accès n'est lié à aucun client spécifique. Cela signifie que le client ne sait pas si ce jeton était destiné à lui ou à une autre application.
Ce jeton est ensuite utilisé pour accéder aux données du propriétaire. Lorsque vous souhaitez "authentifier" le propriétaire, vous extrayez généralement son email de ses données et vous l'authentifiez dans votre application (client). Mais, vous ne savez pas qui a transmis ce jeton d'accès à votre client. Est-ce le véritable propriétaire ou un attaquant hébergeant un autre service?
Exemple d'attaque
- Client_Good: un bon client utilisant l'API Google pour authentifier son utilisateur à l'aide du flux implicite
- Client_Bad: un client malveillant utilisant l'API Google et attaquant Client_Good
Client_Bad peut être n'importe quel service. Par exemple, une application Web qui vous permet de télécharger une image dans votre Google Drive. Pour réaliser cette tâche, Client_Bad a besoin d'un jeton d'accès de Google. Il vous demandera donc de lui en fournir un. Ensuite, vous pourrez utiliser son service pour télécharger votre photo.
Ce que vous ne saviez pas, c'est que le jeton d'accès que vous venez de donner à Client_Bad pour télécharger des photos est également un jeton d'accès valide qui pourrait être utilisé avec Client_Good pour vous authentifier. Désormais, le propriétaire de Client_Bad peut vous faire passer pour Client_Good. Si Client_Good était un service essentiel, vous pourriez avoir de sérieux problèmes.
Pourquoi est-il sécurisé pour l'autorisation alors?
C'est sécurisé car si vous donnez l'autorisation à Client_Bad de télécharger une photo en votre nom, peu importe qu'il le fasse directement ou qu'il passe par un autre service pour le faire.
Par exemple, il pourrait y avoir un troisième client, Client_Picture, qui vient également de télécharger une image sur votre Google Drive. Lorsque vous demandez à Client_Bad de télécharger vos données, Client_Bad pourrait déléguer cette tâche à Client_Picture et cela ne vous dérangerait pas car il obtenait le même résultat.
Eh bien, il y a le fait que maintenant une tonne de tiers pourraient avoir accès à vos données mais encore une fois, vous avez convenu que Client_Bad pouvait faire ce qu'il voulait avec ce jeton d'accès lorsque vous l'avez donné. C'est comme passer la clé de vos voitures à votre voisin. Vous avez donné à quelqu'un d'autre le droit d'utiliser cette voiture, il pourrait alors la prêter à un autre voisin pendant un certain temps puis vous la rendre. Le truc, c'est que vous ne savez pas et que vous avez "accepté" cela lorsque vous avez donné le contrôle.
Remarque : Parfois, je me demande si personne ne comprend l'explication ou si j'ai dit quelque chose de mal ... Quoi qu'il en soit, cela est expliqué dans la section 10.16 de la spécification OAuth2 en d'autres termes si cela aide.