Quelle est la différence entre OpenID et OAuth?

il y a trois façons de comparer OAuth et OpenID:

1. Objet

OpenID a été créé pour l'authentification fédérée, c'est-à-dire pour permettre à un tiers d'authentifier vos utilisateurs pour vous, en utilisant des comptes qu'ils ont déjà . Le terme federated est ici critique car le point entier D'OpenID est que n'importe quel fournisseur peut être utilisé (à l'exception des listes blanches). Vous n'avez pas besoin de choisissez à l'avance ou négociez une entente avec les fournisseurs pour permettre aux utilisateurs d'utiliser tout autre compte qu'ils possèdent.

OAuth a été créé pour supprimer la nécessité pour les utilisateurs de partager leurs mots de passe avec des applications tierces . En fait, cela a commencé comme un moyen de résoudre un problème D'OpenID: si vous supportez OpenID sur votre site, vous ne pouvez pas utiliser les identifiants HTTP de base (Nom d'utilisateur et mot de passe) pour fournir une API parce que les utilisateurs n'ont pas de mot de passe sur votre site.

le problème est avec cette séparation de L'OpenID pour l'authentification et de L'Auth pour l'autorisation est que les deux protocoles peuvent accomplir beaucoup des mêmes choses. Ils fournissent chacun un ensemble différent de caractéristiques qui sont souhaitées par différentes implémentations, mais essentiellement, ils sont assez interchangeables. À la base, les deux protocoles sont une méthode de vérification d'assertion (OpenID se limite à l'assertion "c'est qui je suis", tandis que OAuth fournit un "jeton d'accès" qui peut être échangé contre toute assertion supportée via une API).

2. Caractéristiques

les deux protocoles fournissent un moyen pour un site de rediriger un utilisateur ailleurs et de revenir avec une assertion vérifiable. OpenID fournit une assertion d'identité alors que OAuth est plus générique sous la forme d'un jeton d'accès qui peut ensuite être utilisé pour "demander la OAuth fournisseur de questions" . Cependant, ils soutiennent tous différents caractéristiques:

OpenID - la caractéristique la plus importante D'OpenID est son processus de découverte. OpenID ne nécessite pas de codage dur pour chacun des fournisseurs que vous souhaitez utiliser à l'avance. En utilisant discovery, l'utilisateur peut choisir n'importe quel fournisseur tiers qu'il veut authentifier. Cette fonctionnalité de découverte a également causé la plupart des problèmes D'OpenID parce que la façon dont il est mis en œuvre est en utilisant les URIs HTTP comme identificateurs que la plupart des utilisateurs web ne reçoivent tout simplement pas. D'autres fonctionnalités OpenID prend en charge l'enregistrement ad-hoc des clients à l'aide d'un échange DH, d'un mode immédiat pour une expérience utilisateur optimisée et d'un moyen de vérifier les assertions sans faire un autre aller-retour vers le fournisseur.

OAuth - la caractéristique la plus importante de OAuth est le jeton d'accès qui fournit une méthode durable de faire des requêtes supplémentaires. Contrairement à OpenID, OAuth ne se termine pas par une authentification mais fournit un token d'accès pour accéder à ressources additionnelles fournies par le même service tiers. Cependant, puisque OAuth ne supporte pas discovery, il faut présélectionner et coder les fournisseurs que vous décidez d'utiliser. Un utilisateur visitant votre site ne peut utiliser aucun identifiant, seulement ceux pré-sélectionnés par vous. En outre, OAuth n'a pas de concept d'identité, donc l'utiliser pour se connecter signifie soit ajouter un paramètre personnalisé (comme fait par Twitter) ou faire un autre appel API pour obtenir l'utilisateur actuellement "connecté".

3. Mise En Œuvre Technique

les deux protocoles partagent une architecture commune dans l'utilisation de la redirection pour obtenir l'autorisation de l'utilisateur. En outre, l'Utilisateur autorise L'accès à ses ressources protégées et, en toute transparence, à son identité. Mais c'est tout ce qu'ils partagent.

chaque protocole a un mode de calcul différent d'une signature utilisée pour vérifier l'authenticité de la requête ou de la réponse, et chaque protocole a un enregistrement différent exigence.

OpenID est (principalement) pour l'identification/authentification, de sorte que stackoverflow.com sait que je possède chris.boyle.name (ou n'importe où) et donc que je suis probablement la même personne qui a possédé chris.boyle.name hier et a gagné quelques points de réputation.

OAuth est conçu pour l'autorisation de prendre des mesures en votre nom, de sorte que stackoverflow.com (ou n'importe où) peut demander la permission de, dire, tweeter en votre nom automatiquement, sans connaître votre mot de passe Twitter.

beaucoup de gens visitent encore ce si voici un diagramme très simple pour l'expliquer

Avec La Permission De Wikipedia

OAuth

utilisé pour la délégation authorization seulement -- ce qui 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" sont généralement plus longues que les sessions utilisateur. Ce qui signifie que L'OAuth est conçu pour permettre l'autorisation

, C'est-à-dire que Flickr utilise OAuth pour permettre à des services tiers d'afficher et d'éditer une image de personne sur leur en leur nom, sans qu'ils aient à donner leur nom d'utilisateur et leur mot de passe.

OpenID

utilisé pour authenticate single sign-on identity. Tout ce que OpenID est censé faire est de permettre à un fournisseur OpenID de prouver que vous le dites. Cependant, de nombreux sites utilisent l'authentification d'identité pour fournir une autorisation (cependant 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) le nom de la personne qui est sur le billet qu'ils utilisent est eux.

utilisez OAuth si vos utilisateurs pourraient juste vouloir se connecter avec Facebook, ou Twitter. Utilisez OpenID si vos utilisateurs sont des neckbeards qui gèrent leurs propres fournisseurs OpenID parce qu'ils "ne veulent pas que quelqu'un d'autre possède leur identité".

OpenID et OAuth sont chacun des protocoles HTTP d'authentification et/ou d'autorisation. Les deux sont destinés à permettre aux utilisateurs d'effectuer des actions sans donner des justificatifs d'authentification ou des permissions générales aux clients ou à des tiers. Bien qu'elles soient semblables et qu'il existe des normes proposées pour les utiliser ensemble, il s'agit de protocoles distincts.

OpenID est destiné à l'authentification fédérée. Un client accepte une affirmation d'identité de n'importe quel fournisseur (bien que les clients soient libres de proposer des listes blanches ou des listes noires).

OAuth est prévu pour les délégués de l'autorisation. Un client s'enregistre auprès d'un fournisseur, qui fournit des jetons d'autorisation qu'il acceptera pour effectuer des actions au nom de l'utilisateur.

OAuth est actuellement mieux adapté pour l'autorisation, car d'autres interactions après authentification sont intégrées dans le protocole, mais les deux protocoles évoluent. OpenID et ses extensions pourraient être utilisé pour l'autorisation, et OAuth peut être utilisé pour l'authentification, qui peut être considérée comme une autorisation no-op.

je pense qu'il est logique de revenir sur cette question comme cela a également été souligné dans les commentaires, L'introduction D'OpenID Connect a peut-être apporté plus de confusion.

OpenID Connect est un protocole D'authentification comme OpenID 1.0/2.0, mais il est en fait construit sur OAuth 2.0, donc vous obtiendrez des fonctionnalités d'autorisation avec 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, OpenID Connect:

OpenID est un protocole d'authentification tandis que OAuth est autorisation. L'authentification est sûr que le gars que vous parlez est bien qui il prétend être. Autorisation est d'environ décider ce que ce type devrait être autorisé à faire.

dans OpenID, l'authentification est déléguée: le serveur a veut authentifier l'utilisateur U, mais les justificatifs D'identité de U (par exemple le nom et le mot de passe de U) sont envoyés à un autre serveur, B, qu'un trusts (au moins, trusts pour authentifier utilisateur.) En effet, le serveur B s'assure que U est bien U, et dit à A: "ok, c'est le vrai U".

à 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 aux serveurs pour obtenir l'accès; b peut ainsi fournir des clés d'accès temporaires et spécifiques à un sans donner trop de puissance. Vous pouvez imaginer un serveur OAuth comme le maître de la clé dans un grand hôtel; il donne aux employés clés qui ouvrent les portes de la les chambres qu'ils sont censés entrer, mais chaque clé est limité (il ne donne pas accès à toutes les chambres); en outre, les touches s'autodétruisent après quelques heures.

dans une certaine mesure, l'autorisation peut donner lieu à des abus pseudo-authentification, sur la base que si l'entité a obtient de B la clé d'accès par OAuth, et le montre au serveur S, puis le serveur s peut en déduire que B a authentifié A avant d'accorder la clé d'accès. De sorte que certains les gens utilisent OAuth où ils devraient utiliser OpenID. Ce schéma peut ou peut - être pas éclairant, mais je pense que cette pseudo-authentification est plus de confusion qu'autre chose. OpenID Connect ne fait que cela: il abuse Outh dans un protocole d'authentification. Dans l'hôtel analogie: si je rencontrer un employé présumé et cette personne me montre qu'il a un clé ouvre ma chambre, alors je suppose que c'est un vrai employé, sur la base que le maître de la clé ne lui aurait pas donné une clé qui ouvre ma chambre s'il ne l'était pas.

(source)

en quoi OpenID Connect diffère-t-il D'OpenID 2.0?

OpenID Connect exécute plusieurs des mêmes tâches que OpenID 2.0, mais ne donc, d'une manière qui est API-friendly, et utilisable par natif et mobile application. OpenID Connect définit des mécanismes optionnels pour les la signature et le chiffrement. Tandis que l'intégration de la version 1.0 A et de la version 2.0 nécessite une extension, dans OpenID Connect, les fonctionnalités D'OAuth 2.0 sont intégrées au protocole lui-même.

(source)

OpenID connect vous donnera un token d'accès plus un token d'identification. ID token est un JWT et contient des informations à propos de l'utilisateur authentifié. Il est signé par le fournisseur d'identité et peut être lu et vérifié sans accès au fournisseur d'identité.

en outre, OpenID connect standardise un certain nombre de choses qui oauth2 laisse le choix. par exemple scopes, endpoint discovery, et l'enregistrement dynamique des clients.

Cela rend plus facile d'écrire du code qui permet à l'utilisateur de choisir entre plusieurs fournisseurs d'identité.

(source)

Google's OAuth 2.0

les API Google'S outh 2.0 peuvent être utilisées à la fois pour l'authentification et autorisation. Ce document décrit notre mise en œuvre de OAuth 2.0 pour l'authentification, qui est conforme à L'OpenID Connect spécification, et est certifié OpenID. La documentation présente dans en utilisant OAuth 2.0 pour accéder à Google APIs s'applique également à ce service. Si vous souhaitez explorer ce protocole de façon interactive, nous vous recommandons Google OAuth 2.0 Playground .

(source)

plus une extension à la question qu'une réponse, mais il peut ajouter une certaine perspective aux grandes réponses techniques ci-dessus. Je suis un programmeur expérimenté dans un certain nombre de domaines, mais un noob total à la programmation pour le web. J'essaie maintenant de construire une application basée sur le web en utilisant Zend Framework.

va certainement mettre en œuvre une interface d'authentification de base de nom d'utilisateur/mot de passe spécifique à l'application, mais reconnaître que pour un nombre croissant d'utilisateurs la pensée de encore un autre nom d'utilisateur et mot de passe est dissuasif. Bien que ce ne soit pas vraiment un réseau social, je sais qu'un très grand pourcentage des utilisateurs potentiels de l'application ont déjà des comptes facebook ou twitter. L'application ne veut pas vraiment ou n'a pas besoin d'accéder à des informations sur le compte de l'utilisateur à partir de ces sites, il veut juste offrir la commodité de ne pas exiger de l'utilisateur de mettre en place de nouveaux justificatifs d'identité de compte si elles ne le veulent pas. D'un point de vue fonctionnel, cela semble une affiche enfant pour OpenID. Mais il semble que ni facebook ni twitter ne soient des fournisseurs D'OpenID en tant que tels, bien qu'ils soutiennent l'authentification Auauth pour accéder aux données de leurs utilisateurs.

dans tous les articles que j'ai lus sur les deux et comment ils diffèrent, il ne wan pas jusqu'à ce que 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 no-op" que j'ai vu toute 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 un membre à l'époque, j'ai regardé longuement et durement au bas de cette page aux options pour m'identifier. L'option d'utiliser un login OpenID ou d'en obtenir un si je n'en avais pas, mais rien sur twitter ou facebook, semblait suggérer Qu'OAuth n'était pas adéquat pour le travail. Mais ensuite j'ai ouvert une autre fenêtre et j'ai cherché le processus général d'inscription pour stackoverflow - et voici il y a un slew des options d'authentification de tiers, y compris facebook et twitter. En fin de compte, j'ai décidé d'utiliser mon identifiant google (qui est un OpenID) pour exactement la raison que je ne voulais pas accorder l'accès stackoverflow à ma liste d'amis et tout ce que facebook aime partager sur ses utilisateurs - mais au moins c'est une preuve que OAuth est adéquat pour l'usage que j'avais en tête.

Ce serait vraiment génial si quelqu'un pouvait publier des informations ou des pointeurs vers des informations pour soutenir ce genre de multiples configurations d'autorisation en troisième partie, et la façon dont vous traitez avec les utilisateurs qui révoquent l'autorisation ou perdent l'accès à leur site tiers. J'ai aussi l'impression que mon nom d'utilisateur identifie ici un compte stackoverflow unique auquel je pourrais accéder avec une authentification de base si je voulais le configurer, et aussi accéder à ce même compte via d'autres authentificateurs tiers (par exemple, de sorte que je serais considéré comme connecté à stackoverflow si j'étais connecté à google, facebook ou twitter...). Depuis ce site le fait, quelqu'un ici a probablement un assez bon aperçu sur le sujet. :- )

désolé cela a été si long, et plus une question qu'une réponse - mais la remarque de Karl a fait paraître comme l'endroit le plus approprié pour poster parmi le volume de fils sur OAuth et OpenID. S'il y a un meilleur endroit pour ça que je n'ai pas trouvé, je m'excuse d'avance, j'ai essayé.

OpenID Connect (OIDC) est un protocole d'authentification, basé sur la famille de spécifications OAuth 2.0 (i.e. o pen Auth orization). Il utilise de simples JSON Web Tokens (JWT), que vous pouvez obtenir en utilisant des flux conformes aux spécifications outh 2.0 . outh est directement lié à OpenID Connect (OIDC) depuis OIDC est une couche d'authentification construite sur le dessus de outh 2.0

alors que OAuth 2.0 concerne L'accès aux ressources et le partage, C'est-à-dire L'autorisation, OIDC concerne l'authentification de l'utilisateur. Son but est de vous donner accès à plusieurs sites. Chaque fois que vous devez vous connecter à un site Web en utilisant OIDC , vous êtes redirigé vers votre site OpenID où vous vous connectez, et puis reprise sur le site web.

OpenID Connect (OIDC) est une couche d'authentification au-dessus de outh 2.0, un framework d'autorisation. La norme est contrôlée par la Fondation OpenID.:

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é avec succès auprès de Google et que vous avez autorisé Auth0 à accéder à vos informations, Google vous renvoie à Auth0 informations sur l'utilisateur et l'authentification effectuée. Cette information est retournée dans un JSON Web Token (JWT). Vous recevrez un jeton D'accès et, si demandé, un jeton D'identification. Types de Token : Source: OpenID Connect

analogie :

Une Organisation utilise carte D'identité à des fins d'identification et il contient des puces, il stocke des détails sur L'employé avec autorisation c.-à-d. L'accès Campus/porte/ODC. Carte d'identité agir comme un OIDC et Puce agir comme un OAuth . autres exemples

OpenID prouve qui vous êtes.

OAuth donne accès aux caractéristiques fournies par la partie d'autorisation.

je travaille actuellement sur OAuth 2.0 et OpenID connect spec. Donc voici ma compréhension: Plus tôt ils étaient:

1. OpenID était la mise en œuvre propriétaire de Google permettant des applications tierces comme pour les sites de journaux, vous pouvez vous connecter en utilisant google et de commenter un article et ainsi de suite sur d'autres usecases. Donc essentiellement, pas de partage de mot de passe sur le site Web du journal. Permettez-moi de mettre en place une définition, cette approche dans l'entreprise est appelé Fédération. Dans la Fédération, Vous avez un serveur où vous authentifiez et autorisez (appelé IDP, Fournisseur D'identité) et généralement le gardien des justificatifs D'identité des utilisateurs. l'application client où vous avez des affaires est appelé fournisseur de services ou SP. Si nous revenons à l'exemple du même site Web de journal, alors le site Web de journal est SP here et Google est IDP. Dans l'entreprise ce problème a été résolu auparavant en utilisant SAML. cette fois XML utilisé pour gouverner l'industrie du logiciel. Donc, de webservices à la configuration, tout utilisé pour aller à XML donc nous avons SAML, un protocole complet de la Fédération

2. OAuth: OAuth a vu son émergence comme une norme en regardant toutes ces approches propriétaires et donc nous avons eu OAuth 1.o en règle générale, mais ne concerne que l'autorisation. Pas beaucoup de gens remarqué, mais il a commencé à ramasser. Puis nous avons eu OAuth 2.0 en 2012. Les CTO, les architectes ont commencé à prêter attention alors que le monde se dirige vers le Cloud computing et que les dispositifs informatiques se dirigent vers mobiles et autres appareils de ce type. Un autre type de solution est considéré comme la résolution de problèmes majeurs où les clients logiciels peuvent fournir un service IDP à une entreprise et bénéficier de nombreux services de différents fournisseurs tels que salesforce, SAP, etc. Donc l'intégration ici ressemble vraiment à un scénario de la Fédération bit un gros problème, l'utilisation de SAML est coûteux donc allons explorer OAuth 2.O. Ohh, manqué un point important que pendant cette période, Google a senti que OAuth ne s'adresse pas en fait authentification, comment IDP donnera données utilisateur à SP (qui est en fait merveilleusement abordé dans SAML) et avec d'autres détails comme:

   un. OAuth 2.o ne dit pas clairement comment l'inscription des clients se fera B. il ne mentionne rien à propos de L'interaction entre SP (Resource Server) et l'application client (comme Analytics Server qui fournit des données est Resource Server et l'application qui affiche que les données sont Client)

il y a déjà des réponses merveilleuses données ici techniquement, j'ai pensé à donner de donner une brève perspective d'évolution

OpenId utilise OAuth pour traiter l'authentification.

par analogie, C'est comme si .NET s'appuyait sur L'API Windows. Vous pouvez appeler directement L'API Windows, mais ses arguments sont si larges, si complexes et si vastes que vous pourriez facilement faire des erreurs/bogues/problème de sécurité.

idem avec OpenId / OAuth. OpenId s'appuie sur OAuth pour gérer L'authentification mais définit un Token spécifique (Id_token), une signature numérique et des flux particuliers.

j'aimerais aborder un aspect particulier de cette question, tel que décrit dans ce commentaire:

OAuth: avant d'accorder l'accès à une caractéristique, l'authentification doit être faite, non ?. alors OAuth = Qu'est-ce que OpenId + permet d'accéder à certaines fonctionnalités ? – Hassan Makarov 21 Juin à 1:57

Oui... et pas de. La réponse est subtile, alors soyez indulgents.

quand le flux D'eau vous redirige vers une cible service (OAuth au fournisseur, qui est), il est probable que vous aurez besoin de s'authentifier auprès de ce service avant un jeton sera remis à l'application client/service. Le token résultant permet alors à l'application client de faire des requêtes au nom d'un utilisateur donné.

Note la généralité de cette dernière phrase: plus précisément, j'ai écrit "au nom d'un utilisateur", pas "au nom de vous ". C'est une erreur de supposer que "avoir une capacité à interagir avec une ressource détenue par un utilisateur donné" implique "vous et le propriétaire de la ressource cible(s) sont une seule et même chose".

ne faites pas cette erreur.

bien qu'il soit vrai que vous vous authentifiez avec le fournisseur D'origine (par exemple, par nom d'utilisateur et mot de passe, ou peut-être SSL client certs, ou quelque autre moyen), ce que le client obtient en retour devrait pas nécessairement être considéré comme une preuve de l'identité. Un exemple serait un flux dans lequel l'accès aux ressources d'un autre utilisateur était délégué à vous (et par procuration, le client OAuth). L'autorisation n'implique pas l'authentification.

pour gérer l'authentification, vous voudrez probablement examiner OpenID Connect, qui est essentiellement une autre couche au-dessus de la fondation définie par OAuth 2.0. Voici une citation que capture (à mon avis), les plus saillants concernant OpenID Connect (à partir de https://oauth.net/articles/authentication/ ):

OpenID Connect est un standard ouvert publié début 2014 qui définit une manière interopérable d'utiliser OAuth 2.0 pour effectuer l'authentification des utilisateurs. Essentiellement, il s'agit d'une recette de caramel au chocolat qui a été largement publiée et qui a fait ses preuves auprès d'un grand nombre et d'une grande variété d'experts. Au lieu de construire un protocole différent pour chaque fournisseur d'identité potentiel, une application peut parler d'un protocole à autant de fournisseurs qu'ils veulent travailler avec. Étant donné qu'il s'agit d'une norme ouverte, OpenID Connect peut être implémenté par n'importe qui sans restriction ni problème de propriété intellectuelle.

OpenID Connect est construit directement sur OAuth 2.0 et dans la plupart des cas est déployé directement avec (ou sur) une infrastructure OAuth. OpenID Connect utilise également la signature D'objet JSON et le cryptage (JOSE) ensemble de spécifications pour le transport d'informations signées et cryptées dans différents endroits. En fait, un déploiement OAuth 2.0 avec les capacités JOSE est déjà un long chemin pour définir un système de connexion OpenID entièrement conforme, et le delta entre les deux est relativement petit. Mais ce delta fait une grande différence, et OpenID Connect parvient à éviter de nombreux écueils discutés ci-dessus en ajoutant plusieurs composants clés à la base de OAuth: [...]

Le document décrit ensuite (entre autres choses) des ID de token et un paramètre UserInfo. Le premier fournit un ensemble de revendications (qui vous êtes, quand le jeton a été émis, etc, et peut-être une signature pour vérifier l'authenticité du jeton via une clé publique publiée sans d'avoir à demander le service en amont), et le second fournit un moyen par exemple de demander le premier/dernier nom de l'utilisateur, email, et bits similaires d'information, le tout d'une manière normalisée (par opposition à la ad-hoc extensions à OAuth que les gens utilisaient avant OpenID Connect normalisée des choses).

OAuth construit l'authentification en plus de l'autorisation: l'utilisateur délègue l'accès à son identité à l'application, qui, alors, devient un consommateur de l'API d'identité, découvrant ainsi qui a autorisé le client en premier lieu http://oauth.net/articles/authentication/