Pourquoi utiliser OpenID Connect au lieu de plain OAuth2?
Je viens de commencer à utiliser OAuth 2. comme moyen d'authentifier mes utilisateurs. Cela fonctionne très bien - j'utilise simplement l'API d'identité/profil de chaque fournisseur pour obtenir une adresse e-mail validée de l'utilisateur.
Maintenant, j'ai lu OpenID Connect et je suis un peu confus.
Quelle est la différence entre OpenID Connect et l'utilisation de l'API d'identité sur OAuth2? Est-ce juste que j'ai une API de profil standard, donc je n'ai pas à me soucier si j'obtiens un "email" ou un "emails" JSON de retour?
Ou y a-t-il plus, ce qui rend l'approche OpenID Connect plus sûre que ma première approche?
La connexion OpenID vous donnera un jeton d'accès plus un jeton id . Le jeton d'identification est un JWT et contient des informations sur l'utilisateur authentifié. Il est signé par le fournisseur d'identité et peut être lu et vérifié sans accéder au fournisseur d'identité.
De plus, OpenID connect standardise pas mal de choses qu'oauth2 laisse au choix. par exemple, les étendues, la découverte des points de terminaison et l'enregistrement dynamique des clients.
Cela facilite l'écriture de code qui permet à l'utilisateur de choisir entre plusieurs fournisseurs d'identité.
OAuth fournit uniquement et ne doit fournir qu'une autorisation à l'aide d'un jeton d'accès. La connexion OpenID est construite sur OAuth 2 afin de fournir des informations d'authentification des utilisateurs. Cependant, elle ne vous fournira pas une implémentation plus robuste que OAuth (car elle utilise OAuth et ajoutez des interactions supplémentaires avec un fournisseur OpenID).
OpenID Connect 1.0 est une simple couche d'identité au-dessus du protocole OAuth 2.0 [RFC6749]. Il permet aux clients de vérifier l'identité de l'utilisateur final en fonction de l'authentification effectuée par un serveur d'autorisation, ainsi que pour obtenir des informations de profil de base sur l'utilisateur final de manière interopérable et de type REST. OpenID Connect Core 1.0 - draft 17
OpenID connect vous offre un moyen "standard" d'obtenir l'identité de l'utilisateur. Si vous utilisez OAuth et l'API, vous devez adapter votre demande pour chaque ressource, qui peut ne pas toujours fournir les mêmes informations ou changer au fil du temps. Et conceptuellement, vous utilisez OAuth pour être autorisé à utiliser une API, pas pour authentifier un utilisateur.
En arrière-plan, les spécifications OAuth 2.0 Authorization Framework [RFC6749] et OAuth 2.0 Bearer Token Usage [RFC6750] fournissent un cadre général permettant aux applications tierces d'obtenir et utilisent un accès limité aux ressources HTTP. Ils définissent des mécanismes pour obtenir et utiliser des jetons d'accès pour accéder aux ressources mais ne définissent pas de méthodes standard pour fournir des informations d'identité. Notamment, sans profilage OAuth 2.0, il est incapable de fournir des informations sur l'authentification d'un utilisateur final. OpenID Connect Core 1.0 - draft 17
Notez qu'OpenID connect fournit un id_token avec quelques informations sur l'utilisateur. Cependant, si vous voulez l'ensemble des informations, vous avez toujours besoin du access_token pour demander au fournisseur OpenID d'obtenir les informations utilisateur (ce qui m'a dérouté la première fois que je l'ai vu). Cela montre que demander des informations utilisateur à une API ou au fournisseur OpenID utilise presque la même méthode. Voir 5.3.1. userinfo request dans le projet.
OAuth est un protocole d'autorisation, fournissant un moyen de donner l'autorisation d'accéder à une ressource protégée. Un sous-produit du processus d'autorisation est que l'utilisateur est authentifié.
Techniquement, OAuth n'a pas à vous donner d'informations sur l'utilisateur. Ce qu'il fournit est une validation que l'utilisateur a donné à l'application l'autorisation d'accéder à certaines données. Ceci est régi par la portée de l'octroi de l'autorisation.
OpenID Connect permet à l'application de récupérer des informations sur l'utilisateur authentifié. Plus important encore, il fournit un niveau d'assurance que les informations sont valides (en ce qui concerne le serveur d'autorisation de toute façon). Cela peut ensuite être utilisé pour faciliter la fédération des identités.
Dans le passé, la fédération était réalisée avec OAuth en accordant une étendue qui permettait d'accéder aux informations d'identité de l'utilisateur. OpenID Connect standardise cette étendue.
OpenID Connect est un profil d'OAuth2 ... définissant une architecture qui permet à une personne d'autoriser un fournisseur d'identité à divulguer certaines revendications utilisateur à un client (site Web/application mobile).
OAuth2 offre le Resource Owner Password Credential Grant, qui est à juste titre dénigré par les experts IAM comme "The Devil".
Un modèle commun pour OpenID Connect API est en trois étapes:
1) Obtenez un code
2) Obtenez des jetons comme access_token, refresh_token, et id_token
3) Obtenez des informations utilisateur qui contiennent des revendications telles que nom d'utilisateur, e-mail, etc.
Le schéma de l'id_token, qui est un JWT, est défini dans la portée d'OpenID Connect, ainsi que de nombreux autres détails.
Une autre raison d'utiliser OpenID Connect est qu'il existe une solution sécurisée d'authentification centralisée pour les logiciels mobiles (au moins IOS et Android). La meilleure pratique actuelle définie par Google consiste à utiliser de nouvelles fonctionnalités de sécurité qui empêcher une application mobile de voir les cookies ou les informations d'identification dans une vue Web. Google a publié les bibliothèques AppAuth IOS et Android parce qu'elles ne veulent vraiment pas que vous fuyiez) Au moment d'écrire ces lignes, plusieurs fournisseurs OpenID (alias IDP ...) prennent en charge le logiciel Google OpenID Connect AppAuth, notamment: Google, OKTA, Ping et mon produit Gluu.
Voir également:
- OAuth 2.0 pour les applications natives draft-wdenniss-oauth-native-apps-02
- AppAuth pour IOS
- AppAuth pour Android
L'utilisation de OAuth comme méthode d'authentification n'est pas recommandée, elle est explicitement conçue comme méthode d'autorisation déléguée.
Facebook utilisait OAuth comme méthode d'authentification, mais une personne entreprenante a découvert comment voler le access_token de Facebook - entrée de blog complète
OpenID Connect rend beaucoup plus difficile le vol de jetons d'accès via un tel mécanisme.
Open id connect est construit sur le dessus de OAuth et donc il est plus robuste. OAuth est le protocole qui est utilisé uniquement pour l'autorisation et open id connect est très similaire à OAuth mais il combine la fonctionnalité de OAuth également. Vous pouvez démarrer la communication entre vos RP et IP en utilisant ce protocole et ce sont divers trous de boucle dans OAuth protocol c'est pourquoi il vaut mieux utiliser Open Id Connect.