Quelle est la différence entre OpenID et OAuth?
J'essaie vraiment de comprendre la différence entre OpenID et OAuth? Peut-être que ce sont deux choses totalement séparées?
OpenID concerne l’authentification (pour prouver votre identité), OAuth concerne l’autorisation (pour autoriser l’accès à la fonctionnalité/data/etc. sans avoir à traiter l’authentification initiale).
OAuth pourrait être utilisé sur des sites partenaires externes pour permettre l'accès à des données protégées sans qu'ils aient à réauthentifier un utilisateur.
Le billet de blog " OpenID contre OAuth du point de vue de l'utilisateur " présente une comparaison simple des deux points de vue de l'utilisateur et " OAuth-OpenID: Vous êtes en train de grogner le mauvais arbre si vous pensez qu'ils sont la Même chose "a plus d'informations à ce sujet.
Il existe trois façons de comparer OAuth et OpenID:
1. Objectifs
OpenID a été créé pour l'authentification fédérée, c'est-à-dire pour permettre à un tiers d'authentifier vos utilisateurs, en utilisant des comptes qu'ils ont déjà . Le terme fédéré est essentiel ici car OpenID a pour objectif fondamental de pouvoir utiliser n'importe quel fournisseur (à l'exception des listes blanches). Vous n'avez pas besoin de pré-choisir ou de négocier un accord avec les fournisseurs pour permettre aux utilisateurs d'utiliser n'importe quel autre compte qu'ils ont.
OAuth a été créé pour supprimer la nécessité pour les utilisateurs de partager leurs mots de passe avec des applications tierces . Cela a en fait commencé par un moyen de résoudre un problème OpenID: si vous prenez en charge OpenID sur votre site, vous ne pouvez pas utiliser les informations d'identification HTTP Basic (nom d'utilisateur et mot de passe) pour fournir une API car les utilisateurs n'ont pas de mot de passe sur votre site.
Le problème est que cette séparation entre OpenID pour l'authentification et OAuth pour l'autorisation est que les deux protocoles peuvent accomplir beaucoup des mêmes choses. Ils fournissent chacun un ensemble différent de fonctionnalités qui sont souhaitées par différentes implémentations, mais elles sont essentiellement interchangeables. À la base, les deux protocoles sont une méthode de vérification d'assertion (OpenID est limité à l'assertion «c'est qui je suis», tandis que OAuth fournit un «jeton d'accès» qui peut être échangé contre toute assertion prise en charge via une API).
2. Caractéristiques
Les deux protocoles permettent à un site de rediriger un utilisateur ailleurs et de revenir avec une assertion vérifiable.OpenID fournit une assertion d'identité tandis que OAuth est plus générique sous la forme d'un jeton d'accès qui peut ensuite être utilisé pour "poser des questions au fournisseur OAuth". Cependant, ils supportent chacun des fonctionnalités différentes:
OpenID - La fonctionnalité la plus importante d’OpenID est son processus de découverte. OpenID ne nécessite pas de codage en dur chacun des fournisseurs que vous souhaitez utiliser à l'avance. À l'aide de la découverte, l'utilisateur peut choisir n'importe quel fournisseur tiers à authentifier. Cette fonctionnalité de découverte est également à l'origine de la plupart des problèmes d'OpenID, car elle est implémentée en utilisant des URI HTTP comme identificateurs, ce que la plupart des utilisateurs Web ne comprennent tout simplement pas. Autres caractéristiques OpenID prend en charge l’enregistrement de client ad hoc en utilisant un échange DH, le mode immédiat pour une expérience utilisateur optimisée et un moyen de vérifier les assertions sans effectuer un autre aller-retour vers le fournisseur.
OAuth - La caractéristique la plus importante d'OAuth est le jeton d'accès, qui fournit une méthode durable pour la création de requêtes supplémentaires. Contrairement à OpenID, OAuth ne se termine pas avec l'authentification mais fournit un jeton d'accès pour accéder aux ressources supplémentaires fournies par le même service tiers. Cependant, comme OAuth ne prend pas en charge la découverte, il est nécessaire de présélectionner et de coder en dur les fournisseurs que vous décidez d'utiliser. Un utilisateur visitant votre site ne peut utiliser aucun identifiant, uniquement ceux que vous avez présélectionnés. De plus, OAuth n’ayant pas de concept d’identité, son utilisation pour la connexion signifie soit l’ajout d’un paramètre personnalisé (comme le fait Twitter), soit un autre appel d’API pour obtenir l’utilisateur actuellement "connecté".
3. Implémentations techniques
Les deux protocoles partagent une architecture commune d'utilisation de la redirection pour obtenir l'autorisation de l'utilisateur. Dans OAuth, l'utilisateur autorise l'accès à ses ressources protégées et à OpenID, à son identité. Mais c'est tout ce qu'ils partagent.
Chaque protocole utilise une méthode différente pour calculer une signature utilisée pour vérifier l’authenticité de la demande ou de la réponse, et chacun a des exigences d’enregistrement différentes.
OpenID est (principalement) utilisé pour l'identification/l'authentification, de sorte que stackoverflow.com sache que je possède chris.boyle.name (ou ailleurs) et que je suis probablement la même personne que celle qui possédait chris.boyle.name hier et qui a gagné des points de réputation.
OAuth est conçu pour autoriser des actions en votre nom, de sorte que stackoverflow.com (ou ailleurs) puisse demander l'autorisation de, par exemple, de tweeter en votre nom automatiquement, sans connaître votre mot de passe Twitter.
Beaucoup de gens visitent encore ceci alors voici un schéma très simple pour l'expliquer
OAuth
Utilisé uniquement pour authorization déléguée - cela signifie que vous autorisez un accès à un service tiers à utiliser des données personnelles, sans donner de mot de passe. De plus, les "sessions" OAuth vivent généralement plus longtemps que les sessions utilisateur. Ce qui signifie que OAuth est conçu pour permettre l'autorisation
c'est-à-dire que Flickr utilise OAuth pour permettre aux services tiers de publier et de modifier une photo de personne en leur nom, sans que ceux-ci aient à donner leur nom d'utilisateur et leur mot de passe scintillants.
OpenID
Utilisé pour authenticate identité de connexion unique. Tout ce que OpenID est censé faire est de permettre à un fournisseur OpenID de prouver que vous dites que vous êtes. Cependant, de nombreux sites utilisent une authentification d’identité pour fournir une autorisation (toutefois, les deux peuvent être séparés).
c'est-à-dire que l'un d'eux montre son passeport à l'aéroport pour authentifier (ou prouver) que le nom de la personne qui figure sur le billet utilisé est celui-ci.
Utilisez OAuth si vos utilisateurs peuvent simplement vouloir se connecter avec Facebook ou Twitter. Utilisez OpenID si vos utilisateurs sont des hommes qui exploitent leurs propres fournisseurs OpenID, car ils "ne veulent pas que quiconque possède leur identité".
OpenID et OAuth sont chacun des protocoles basés sur HTTP pour l'authentification et/ou l'autorisation. Les deux sont destinés à permettre aux utilisateurs d'effectuer des actions sans donner des informations d'authentification ni des autorisations générales à des clients ou à des tiers. Bien qu'ils soient similaires et qu'il existe des normes proposées pour les utiliser ensemble, ils constituent des protocoles distincts.
OpenID est destiné à l'authentification fédérée. Un client accepte une assertion d'identité de n'importe quel fournisseur (bien que les clients soient libres d'ajouter des fournisseurs à la liste blanche ou noire).
OAuth est destiné à une autorisation déléguée. Un client s'inscrit auprès d'un fournisseur, qui fournit des jetons d'autorisation qu'il acceptera d'effectuer des actions pour le compte de l'utilisateur.
OAuth est actuellement mieux adapté à l'autorisation car d'autres interactions après l'authentification sont intégrées au protocole, mais les deux protocoles évoluent. OpenID et ses extensions pourraient être utilisés pour l'autorisation, et OAuth pour l'authentification, ce qui peut être considéré comme une autorisation no-op.
Je pense qu'il est logique de revenir sur cette question, comme le soulignent également les commentaires. L'introduction d'OpenID Connect aurait pu créer davantage de confusion.
OpenID Connect est un protocole d'authentification similaire à OpenID 1.0/2.0, mais il est en fait basé sur OAuth 2.0. Vous obtiendrez ainsi des fonctionnalités d'autorisation, ainsi que des fonctionnalités d'authentification. La différence entre les deux est assez bien expliquée en détail dans cet article (relativement récent, mais important): http://oauth.net/articles/authentication/
L'explication de la différence entre OpenID, OAuth et OpenID Connect:
OpenID est un protocole d'authentification alors que OAuth est pour autorisation. L'authentification consiste à s'assurer que le gars vous sont en train de parler à qui il prétend être. L'autorisation est d'environ décider de ce que ce gars devrait être autorisé à faire.
Dans OpenID, l'authentification est déléguée: le serveur A veut s'authentifier utilisateur U, mais les informations d'identification de U (par exemple, le nom et le mot de passe de U) sont envoyées à un autre serveur, B, approuvé par A (du moins, pour l’authentification des utilisateurs ). En effet, le serveur B s'assure que U est bien U, puis dit à A: "ok, c'est le véritable U".
Dans OAuth, l'autorisation est déléguée: l'entité A obtient de l'entité B un "droit d'accès" que A peut montrer au serveur S à qui l'accès est accordé; B peut ainsi délivrer des clés d’accès temporaires et spécifiques à A sans donner eux trop de pouvoir. Vous pouvez imaginer un serveur OAuth en tant que maître des clés dans un grand hôtel; il donne aux employés des clés qui ouvrent les portes du chambres qu’ils sont supposés entrer, mais chaque clé est limitée (elle ne donne pas accès à toutes les chambres); de plus, les clés s'autodétruit au bout de quelques heures.
Dans une certaine mesure, l’autorisation peut être utilisée de manière abusive. pseudo-authentification, sur la base que si l'entité A obtient de B un clé d'accès via OAuth et l'affiche au serveur S, le serveur S peut alors déduire que B a authentifié A avant d'accorder la clé d'accès. Donc des les gens utilisent OAuth là où ils devraient utiliser OpenID. Ce schéma peut ou peut ne pas être éclairant; mais je pense que cette pseudo-authentification est plus déroutant que tout. OpenID Connect ne fait que cela: il abuse OAuth dans un protocole d'authentification. Dans l'analogie de l'hôtel: si je rencontrer un employé prétendu et cette personne me montre qu'il a un clé qui ouvre ma chambre, alors je suppose que c'est un vrai employé, sur la base que le maître clé ne lui aurait pas donné une clé qui ouvre ma chambre s'il ne l'était pas.
En quoi OpenID Connect est-il différent d’OpenID 2.0?
OpenID Connect effectue la plupart des tâches identiques à OpenID 2.0, mais le fait de manière conviviale pour les API et utilisable par les utilisateurs natifs et mobiles applications. OpenID Connect définit des mécanismes facultatifs pour robust signature et cryptage. Considérant l’intégration d’OAuth 1.0a et OpenID 2.0 nécessitait une extension. Dans OpenID Connect, les fonctionnalités d’OAuth 2.0 sont intégrées au protocole lui-même.
OpenID Connect vous donnera un jeton d'accès plus un jeton d'identification. L identité Le jeton 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 qui oauth2 laisse au choix. par exemple, étendues, découverte de points de terminaison, et enregistrement dynamique des clients.
Cela facilite l'écriture de code permettant à l'utilisateur de choisir entre plusieurs fournisseurs d'identité.
Google OAuth 2.0
Les API Google OAuth 2.0 peuvent être utilisées à la fois pour l'authentification et autorisation. Ce document décrit notre implémentation de OAuth 2.0 pour l'authentification, qui est conforme à OpenID Connect spécification, et est OpenID Certified. La documentation trouvée dans Utilisation de OAuth 2.0 pour accéder aux API Google s'applique également à ce service. Si vous souhaitez explorer ce protocole de manière interactive, nous vous recommandons le Google OAuth 2.0 Playground .
Plus une extension de la question qu'une réponse, mais cela peut donner une perspective aux grandes réponses techniques ci-dessus. Je suis un programmeur expérimenté dans un certain nombre de domaines, mais je suis totalement novice en programmation pour le Web. Essayez maintenant de créer une application Web à l'aide de Zend Framework.
Certainement implémentera une interface d'authentification de base nom d'utilisateur/mot de passe spécifique à l'application, mais reconnaîtra que pour un nombre croissant d'utilisateurs, le fait de penser à un autre nom d'utilisateur et mot de passe est dissuasif. Bien que ce ne soit pas exactement un réseau social, je sais qu'un très grand pourcentage des utilisateurs potentiels de l'application possède déjà un compte Facebook ou Twitter. L’application ne veut pas ou n’a pas vraiment besoin d’accéder aux informations relatives au compte de l’utilisateur à partir de ces sites, elle veut simplement offrir l’opportunité de ne pas obliger l’utilisateur à configurer de nouvelles informations d’identification de compte s’il ne le souhaite pas. D'un point de vue fonctionnel, cela semblerait un enfant d'affiche pour OpenID. Mais il semble que ni Facebook ni Twitter ne soient des fournisseurs OpenID en tant que tels, bien qu'ils prennent en charge l'authentification OAuth pour accéder aux données de leurs utilisateurs.
Dans tous les articles que j'ai lus à propos des deux et de leurs différences, ce n'est que lorsque j'ai vu l'observation de Karl Anderson ci-dessus que "OAuth peut être utilisé pour l'authentification, ce qui peut être considéré comme une autorisation non-op". J'ai vu une confirmation explicite que OAuth était assez bon pour ce que je voulais faire.
En fait, quand je suis allé poster cette "réponse", n'étant pas membre à l'époque, j'ai longuement et durement regardé les options pour m'identifier. La possibilité d'utiliser un identifiant OpenID ou d'en obtenir un si je n'en avais pas, mais rien sur Twitter ou Facebook, semblait suggérer que OAuth n'était pas adéquat pour le poste. Mais ensuite, j'ai ouvert une autre fenêtre et cherché le processus général d'inscription pour stackoverflow - et voilà, il y a une multitude d'options d'authentification tierces, telles que Facebook et Twitter. En fin de compte, j’ai décidé d’utiliser mon identifiant Google (qui est un OpenID) précisément pour la raison pour laquelle je ne voulais pas accorder d’accès stackoverflow à ma liste d’amis et à tout ce que facebook aime partager avec ses utilisateurs - mais au moins, c’est un preuve que OAuth convient à l’utilisation que j’avais à l’esprit.
Ce serait vraiment bien si quelqu'un pouvait publier des informations ou des pointeurs d'informations sur la prise en charge de ce type de configuration d'autorisation en plusieurs parties, et sur la façon dont vous traitez avec les utilisateurs qui révoquent l'autorisation ou perdent l'accès à leur site tiers. J'ai également l'impression que mon nom d'utilisateur ici identifie un compte unique stackoverflow auquel je pourrais accéder avec une authentification de base si je voulais le configurer, et accéder également à ce même compte via d'autres authentifiants tiers (par exemple pour que je sois considéré comme connecté). dans stackoverflow si j'étais connecté à l'un de google, facebook ou twitter ...). Depuis que ce site le fait, quelqu'un ici a probablement une assez bonne idée sur le sujet. :-)
Désolé, ce fut si long, et plus une question qu'une réponse - mais la remarque de Karl lui a semblé être l'endroit le plus approprié pour publier au milieu du volume de discussions sur OAuth et OpenID. S'il y a un meilleur endroit pour cela que je n'ai pas trouvé, je m'excuse d'avance, j'ai essayé.
Une entité ID (OpenID) et l'autre est Auth orization (OAuth), les deux sont au format Open.
OpenID Connect (OIDC) est un protocole d'authentification basé sur la famille de spécifications OAuth 2.0 (c.-à-d. O pen Auth orh [)]. Il utilise de simples jetons Web JSON (JWT), que vous pouvez obtenir à l'aide de flux conformes aux spécifications OAuth 2.0. OAuth est directement lié à OpenID Connect (OIDC) puisque OIDC est une couche d'authentification construite sur OAuth 2.0.
Alors que OAuth 2.0 concerne l’accès et le partage de ressources, c’est-à-dire les autorisations, OIDC concerne l’authentification des utilisateurs. Son but est de vous donner un identifiant pour plusieurs sites. Chaque fois que vous devez vous connecter à un site Web à l'aide de OIDC, vous êtes redirigé vers votre site OpenID sur lequel vous vous connectez, puis vous êtes redirigé vers le site Web.
OpenID Connect (OIDC) est une couche d'authentification au-dessus de OAuth 2.0, un framework d'autorisation. Le standard est contrôlé par OpenID Foundation .:
Par exemple, si vous avez choisi de vous connecter à Auth0 en utilisant votre compte Google, vous avez utilisé OIDC. Une fois que vous vous êtes authentifié auprès de Google et que vous avez autorisé Auth0 à accéder à vos informations, Google renverra à Auth0 des informations sur l'utilisateur et l'authentification effectuée. Ces informations sont renvoyées dans un jeton Web JSON (JWT). Vous recevrez un jeton d'accès et, si nécessaire, un jeton d'identification. Types de jetons : Source: OpenID Connect
Analogie:
Une organisation utilise ID Card à des fins d’identification. Elle contient des puces, elle stocke des détails sur Employee, ainsi que Authorization, c’est-à-dire un accès Campus/Gate/ODC. ID Card agissent comme un OIDC et Chip agissent comme un OAuth. plus d'exemples
OpenID prouve qui vous êtes.
OAuth autorise l'accès aux fonctionnalités fournies par la personne qui autorise.
Je travaille actuellement sur OAuth 2.0 et OpenID Connect spec. Alors voici ma compréhension: Auparavant, ils étaient:
- OpenID était une implémentation exclusive de Google permettant aux applications tierces, comme pour les sites Web de journaux, de se connecter à l'aide de Google et de commenter un article, etc., ainsi que d'autres cas d'utilisation. Donc, essentiellement, pas de partage de mot de passe pour le site Web du journal. Permettez-moi de vous proposer une définition, cette approche en entreprise s'appelle Fédération. Dans Federation, vous avez un serveur sur lequel vous authentifiez et autorisez (appelé IDP, Fournisseur d'identité) et généralement le détenteur des informations d'identification de l'utilisateur. l'application cliente pour laquelle vous avez des activités s'appelle SP ou fournisseur de services. Si nous revenons au même exemple de site Web de journal, le site Web du journal est SP ici et Google est IDP. En entreprise, ce problème avait été résolu auparavant avec SAML. ce temps XML utilisé pour gouverner l'industrie du logiciel. Ainsi, des services Web à la configuration, tout ce qui était utilisé pour passer en XML a donc SAML, un protocole de fédération complet
OAuth: OAuth considérait son émergence comme une norme examinant tous ces types d'approches propriétaires. Nous avions donc OAuth 1.o en standard mais ne traitait que de l'autorisation. Peu de gens l'ont remarqué, mais ça a commencé à augmenter. Puis nous avons eu OAuth 2.0 en 2012. CTO, les architectes ont vraiment commencé à prêter attention alors que le monde évolue vers l'informatique en nuage et que les appareils informatiques se tournent vers les appareils mobiles et autres. OAuth est en quelque sorte considéré comme un moyen de résoudre le problème majeur suivant: les clients en logiciels pourraient fournir des services IDP à une entreprise et bénéficier de nombreux services de fournisseurs différents tels que salesforce, SAP, etc. L'intégration ressemble donc vraiment à un problème de fédération, mais l'utilisation de SAML est coûteuse alors explorons OAuth 2.o. Ohh, vous avez manqué un point important sur le fait qu'au cours de cette période, Google a senti que OAuth ne traitait pas en réalité de l'authentification. Comment IDP transmettrait-il des données utilisateur à SP (qui est en fait merveilleusement traité dans SAML) et à d'autres points faibles, tels que:
une. OAuth 2.o ne dit pas clairement comment l'enregistrement des clients se fera B. il ne mentionne rien sur l'interaction entre SP (serveur de ressources) et l'application cliente (par exemple, Analytics Server fournissant des données est un serveur de ressources et une application affichant ces données comme client)
Il y a déjà de merveilleuses réponses données ici techniquement, j'ai pensé à donner une brève perspective d'évolution
OAuth 2.0 est un protocole de sécurité. Ce n'est NI une authentification NOR ni un protocole d'autorisation.
L'authentification par définition répond à deux questions.
- Qui est l'utilisateur?
- L'utilisateur est-il présent sur le système?
OAuth 2.0 a les types de subvention suivants
- client_credentials: lorsqu'une application doit interagir avec une autre application et modifier les données de plusieurs utilisateurs.
- autorisation_code: l'utilisateur délègue le serveur d'autorisations pour qu'il émette un code d'accès que le client peut utiliser pour accéder à une ressource protégée.
- refresh_token: lorsque le access_token expire, le jeton d'actualisation peut être utilisé pour obtenir un nouvel access_token
- mot de passe: l'utilisateur fournit ses informations d'identification à un client qui appelle le serveur d'autorisations et reçoit un code d'accès
Tous les 4 ont une chose en commun, access_token, un artefact qui peut être utilisé pour accéder à une ressource protégée.
Access_token ne fournit pas la réponse aux 2 questions auxquelles un protocole "Authentification" doit répondre.
Un exemple pour expliquer Oauth 2.0 (crédits: OAuth 2 in Action, publications de Manning)
Parlons de chocolat. Nous pouvons faire beaucoup de confiseries avec du chocolat, y compris du fudge, de la glace et des gâteaux Mais rien de tout cela ne peut être assimilé au chocolat, car de nombreux autres ingrédients tels que la crème et le pain sont nécessaires à la confection, même si le chocolat sonne comme l’ingrédient principal. De même, OAuth 2.0 est le chocolat, et les cookies, l'infrastructure TLS, les fournisseurs d'identité sont d'autres ingrédients nécessaires pour fournir la fonctionnalité "Authentification".
Si vous voulez l'authentification, vous pouvez opter pour OpenID Connect, qui fournit un "id_token", en plus d'un access_token, qui répond aux questions auxquelles chaque protocole d'authentification doit répondre.
Les deux protocoles ont été créés pour des raisons différentes. OAuth a été créé pour autoriser des tiers à accéder à des ressources. OpenID a été créé pour effectuer la validation d'identité décentralisée. Ce site web indique ce qui suit:
OAuth est un protocole conçu pour vérifier l'identité d'un utilisateur final et pour accorder des autorisations à un tiers. Cette vérification aboutit à un jeton. Le tiers peut utiliser ce jeton pour accéder aux ressources pour le compte de l'utilisateur. Les jetons ont une portée. La portée est utilisée pour vérifier si une ressource est accessible à un utilisateur ou non.
OpenID est un protocole utilisé pour l'authentification décentralisée. L'authentification concerne l'identité. L'établissement de l'utilisateur est en fait la personne qu'il prétend être. Décentraliser cela signifie que ce service ignore l'existence de ressources ou d'applications devant être protégées. C’est la principale différence entre OAuth et OpenID.
OpenId utilise OAuth pour gérer l'authentification.
Par analogie, c'est comme si .NET s'appuyait sur les API Windows. Vous pouvez appeler directement l'API Windows, mais ses arguments sont si vastes, complexes et si nombreux que vous pouvez facilement commettre des erreurs, des bogues ou des problèmes de sécurité.
Idem avec OpenId/OAuth. OpenId s'appuie sur OAuth pour gérer l'authentification, mais en définissant un jeton spécifique (Id_token), une signature numérique et des flux particuliers.