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 distinctes?

OpenID concerne l'authentification (c'est-à-dire prouver qui vous êtes), OAuth concerne l'autorisation (c'est-à-dire accorder l'accès aux fonctionnalités / données / etc. sans avoir à gérer l'authentification d'origine).

OAuth pourrait être utilisé dans des sites partenaires externes pour permettre l'accès aux 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 du point de vue de l'utilisateur et " OAuth-OpenID: vous aboyez le mauvais arbre si vous pensez qu'ils sont la même chose " contient plus d'informations à propos de ça.

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 pour vous, en utilisant les comptes qu'ils ont déjà . Le terme fédéré est critique ici parce que tout l'intérêt d'OpenID est que n'importe quel fournisseur peut être utilisé (à l'exception des listes blanches). Vous n'avez pas besoin de présélectionner ou de négocier un accord avec les fournisseurs pour permettre aux utilisateurs d'utiliser tout autre compte dont ils disposent.

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é comme 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 de base (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 avec cette séparation d'OpenID pour l'authentification et d'OAuth pour l'autorisation est que les deux protocoles peuvent accomplir plusieurs des mêmes choses. Ils fournissent chacun un ensemble différent de fonctionnalités qui sont souhaitées par différentes implémentations mais essentiellement, elles sont assez 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 affirmation 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 prennent chacun en charge différentes fonctionnalités:

OpenID - la caractéristique 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 qu'il souhaite authentifier. Cette fonctionnalité de découverte a également causé la plupart des problèmes d'OpenID parce que la façon dont elle est implémentée consiste à utiliser des URI HTTP comme identifiants que la plupart des utilisateurs Web n'obtiennent tout simplement pas. Les autres fonctionnalités d'OpenID sont sa prise en charge de l'enregistrement client ad hoc à l'aide d'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 avec le fournisseur.

OAuth - la caractéristique la plus importante d'OAuth est le jeton d'accès qui fournit une méthode durable pour effectuer des demandes supplémentaires. Contrairement à OpenID, OAuth ne se termine pas par l'authentification mais fournit un jeton d'accès pour accéder à des ressources supplémentaires fournies par le même service tiers. Cependant, comme OAuth ne prend pas en charge la découverte, il nécessite une présélection et un codage en dur des 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'a pas de concept d'identité, donc l'utiliser pour la connexion signifie soit ajouter un paramètre personnalisé (comme le fait Twitter), soit effectuer un autre appel d'API pour obtenir l'utilisateur actuellement "connecté".

3. Implémentations techniques

Les deux protocoles partagent une architecture commune dans l'utilisation de la redirection pour obtenir l'autorisation utilisateur. Dans OAuth, l'utilisateur autorise l'accès à ses ressources protégées et dans OpenID, à son identité. Mais c'est tout ce qu'ils partagent.

Chaque protocole a une manière différente de 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) pour l'identification / l'authentification, de sorte que stackoverflow.comsache 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.namehier et a gagné quelques points de réputation.

OAuth est conçu pour être autorisé à prendre des mesures en votre nom, afin que stackoverflow.com(ou n'importe où) puisse demander la permission de dire, par exemple, tweeter en votre nom automatiquement, sans connaître votre mot de passe Twitter.

Beaucoup de gens visitent encore ce site alors voici un schéma très simple pour l'expliquer

Courtoisie Wikipedia

OAuth

Utilisé pour délégué authorization uniquement - 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» OAuth vivent généralement plus longtemps que les sessions utilisateur. Cela signifie que OAuth est conçu pour permettre l'autorisation

Par exemple, Flickr utilise OAuth pour permettre à des services tiers de publier et de modifier une photo de personne en leur nom, sans qu'ils aient à donner leur nom d'utilisateur et leur mot de passe.

OpenID

Utilisé pour l' authenticateidentité de connexion unique. OpenID est simplement censé permettre à un fournisseur OpenID de prouver que vous dites que vous l'êtes. Cependant, de nombreux sites utilisent l'authentification d'identité pour fournir une autorisation (mais les deux peuvent être séparés)

c'est-à-dire que l'on montre son passeport à l'aéroport pour authentifier (ou prouver) le nom de la personne dont le nom figure sur le billet qu'elle utilise.

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

• OpenID est un protocole d'authentification standard ouvert et décentralisé contrôlé par la Fondation OpenID.
• OAuth est un standard ouvert pour la délégation d'accès.
• OpenID Connect (OIDC) Combine les fonctionnalités d'OpenID et OAuth, c'est-à-dire qu'il fait à la fois l'authentification et l'autorisation.

OpenID prend la forme d'un URI unique géré par un "fournisseur OpenID", c'est-à-dire un fournisseur d'identité (idP).

OAuth peut être utilisé conjointement avec XACML où OAuth est utilisé pour le consentement de propriété et la délégation d'accès tandis que XACML est utilisé pour définir les politiques d'autorisation.

OIDC 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é à OIDC, car OIDC est une couche d'authentification basée sur OAuth 2.0 .

Par exemple , si vous avez choisi de vous connecter à Auth0 à l' aide de votre compte Google, vous avez utilisé OIDC . Une fois que vous vous êtes authentifié avec Google et que vous autorisez Auth0 à accéder à vos informations, Google renvoie à 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 demandé, un jeton d'identification. Types de jeton : Source: OpenID Connect

Analogie :
Une organisation utilise ID carte à des fins d'identification et il contient des puces, il stocke des détails sur les employés ainsi que l' autorisation c. -à- Campus / Gate / accès ODC. La carte d' identité agit comme un OIDC et la puce agit comme un OAuth . plus d'exemples et formulaire wiki

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 ou des autorisations générales aux clients ou à des tiers. Bien qu'ils soient similaires et qu'il existe des normes proposées pour les utiliser ensemble, ce sont des 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 les mettre sur liste blanche ou sur liste noire).

OAuth est destiné à l'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 au nom 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 peuvent être utilisés pour l'autorisation, et OAuth peut être utilisé pour l'authentification, qui peut être considérée comme une autorisation sans opération.

Je pense qu'il est logique de réexaminer cette question, comme cela a également été souligné dans les commentaires, l'introduction d'OpenID Connect a peut-être semé la confusion.

OpenID Connect est un protocole d'authentification comme OpenID 1.0 / 2.0 mais il est en fait construit au-dessus d'OAuth 2.0, vous obtiendrez donc 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, OpenID Connect:

OpenID est un protocole d'authentification tandis que OAuth est pour l'autorisation. L'authentification consiste à s'assurer que le gars à qui vous parlez est bien celui qu'il prétend être. L'autorisation consiste à 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 informations d'identification de U (par exemple le nom et le mot de passe de U) sont envoyées à un autre serveur, B, que A approuve (au moins, approuve l'authentification des utilisateurs). En effet, le serveur B s'assure que U est bien U, puis dit à A: "ok, c'est le vrai 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 pour obtenir un accès; B peut ainsi fournir des clés d'accès temporaires et spécifiques à A sans leur donner trop de puissance. Vous pouvez imaginer un serveur OAuth comme le maître des clés dans un grand hôtel; il remet aux employés des clés qui ouvrent les portes des pièces où ils sont censés entrer, mais chaque clé est limitée (elle ne donne pas accès à toutes les pièces); de plus, les clés s'autodétruisent au bout de quelques heures.

Dans une certaine mesure, l'autorisation peut être utilisée abusivement dans une pseudo-authentification, sur la base du fait que si l'entité A obtient de B une clé d'accès via OAuth et la montre au serveur S, le serveur S peut déduire que B a authentifié A avant d'accorder l'accès clé. Certaines personnes utilisent donc OAuth là où elles devraient utiliser OpenID. Ce schéma peut être éclairant ou non; mais je pense que cette pseudo-authentification est plus déroutante qu'autre chose. OpenID Connect fait exactement cela: il abuse d'OAuth dans un protocole d'authentification. Dans l'analogie de l'hôtel: si je rencontre un prétendu employé et que cette personne me montre qu'il a une clé qui ouvre ma chambre, alors je suppose que c'est un vrai employé, sur la base que le maître des clés ne lui aurait pas donné de clé ce qui ouvre ma chambre s'il ne l'était pas.

(la source)

En quoi OpenID Connect est-il différent d'OpenID 2.0?

OpenID Connect exécute plusieurs des mêmes tâches qu'OpenID 2.0, mais le fait d'une manière compatible avec l'API et utilisable par les applications natives et mobiles. OpenID Connect définit des mécanismes facultatifs pour une signature et un chiffrement robustes. Alors que l'intégration d'OAuth 1.0a et d'OpenID 2.0 nécessitait une extension, dans OpenID Connect, les capacités d'OAuth 2.0 sont intégrées au protocole lui-même.

(la source)

La connexion OpenID vous donnera un jeton d'accès plus un jeton d'identification. 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é.

(la source)

Google OAuth 2.0

Les API OAuth 2.0 de Google peuvent être utilisées à la fois pour l'authentification et l'autorisation. Ce document décrit notre implémentation OAuth 2.0 pour l'authentification, conforme à la spécification OpenID Connect et certifiée OpenID. La documentation contenue dans Utilisation d'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 .

(la source)

Plus une extension de la question qu'une réponse, mais cela peut ajouter une certaine perspective aux excellentes 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. Nous essayons maintenant de créer une application Web en utilisant Zend Framework.

Certainement implémentera une interface d'authentification de nom d'utilisateur / mot de passe de base spécifique à l'application, mais reconnaît que pour un nombre croissant d'utilisateurs, l'idée d'un autre nom d'utilisateur et mot de passe est dissuasive. 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 ont déjà des comptes Facebook ou Twitter. L'application ne veut pas ou n'a pas vraiment besoin d'accéder aux informations sur le compte de l'utilisateur à partir de ces sites, elle veut simplement offrir la commodité 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 être 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 sur les deux et comment ils diffèrent, ce n'est que lorsque j'ai vu l'observation de Karl Anderson ci-dessus, que "OAuth peut être utilisé pour l'authentification, qui peut être considérée comme une autorisation sans opération" qui 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 regardé longuement et sérieusement au bas de cette page les options pour m'identifier. L'option d'utiliser une connexion OpenID ou d'en obtenir une 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 cherché le processus d'inscription général pour stackoverflow - et voilà, il y a une multitude d'options d'authentification tierces, y compris Facebook et Twitter. En fin de compte, j'ai décidé d'utiliser mon identifiant Google (qui est un OpenID) pour la raison précise que je ne voulais pas accorder à stackoverflow l'accès à ma liste d'amis et à tout ce que Facebook aime partager à propos de ses utilisateurs - mais au moins c'est le cas ''

Ce serait vraiment bien si quelqu'un pouvait publier des informations ou des pointeurs vers des informations sur la prise en charge de ce type de configuration d'autorisations tierces multiples et sur la façon dont vous traitez 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 identifie ici un compte stackoverflow unique 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 authentificateurs tiers (par exemple pour que je sois considéré comme connecté dans stackoverflow si j'étais connecté à Google, Facebook ou Twitter ...). Étant donné que ce site le fait, quelqu'un ici a probablement une assez bonne idée du sujet. :-)

Désolé, cela a été si long, et plus une question qu'une réponse - mais la remarque de Karl 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 ça que je n'ai pas trouvé, je m'excuse d'avance, j'ai essayé.

OpenID prouve qui vous êtes.

OAuth accorde l'accès aux fonctionnalités fournies par l'ordonnateur.

Je travaille actuellement sur OAuth 2.0 et OpenID connect spec. Voici donc ma compréhension: plus tôt, ils étaient:

1. OpenID était une implémentation propriétaire de Google permettant aux applications tierces comme pour les sites Web de journaux, vous pouvez vous connecter en utilisant Google et commenter un article et ainsi de suite d'autres cas d'utilisation. Donc, essentiellement, pas de partage de mot de passe sur le site Web du journal. Permettez-moi de mettre une définition ici, cette approche dans l'approche d'entreprise est appelée Fédération. Dans la fédération, vous disposez d'un serveur sur lequel vous 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 dans laquelle vous travaillez est appelée SP ou Service Provider. Si nous revenons au même exemple de site Web de journal, le site Web de journal est SP ici et Google est IDP. En entreprise, ce problème a été résolu auparavant à l'aide de SAML. ce temps XML utilisé pour gouverner l'industrie du logiciel. Donc, des services Web à la configuration, tout était utilisé pour XML, nous avons donc SAML,

2. OAuth: OAuth a vu son émergence comme une norme en ce qui concerne tous ces types d'approches propriétaires et nous avons donc eu OAuth 1.o en tant que norme, mais uniquement pour l'autorisation. Peu de gens l'ont remarqué mais ça a commencé à reprendre. Ensuite, nous avons eu OAuth 2.0 en 2012. Les CTO, les architectes ont vraiment commencé à prêter attention alors que le monde évolue vers le cloud computing et avec les appareils informatiques vers les appareils mobiles et autres. OAuth est considéré comme la résolution d'un problème majeur dans lequel les clients de logiciels peuvent fournir le service IDP à une entreprise et avoir de nombreux services de différents fournisseurs tels que Salesforce, SAP, etc. explorons donc OAuth 2.o. Ohh, j'ai raté un point important que pendant ce temps, Google a senti que OAuth ne fait pas

   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 (Resource Server) et l'application client (comme Analytics Server fournissant des données est Resource Server et l'application affichant que les données sont Client)

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

OpenId utilise OAuth pour gérer l'authentification.

Par analogie, c'est comme .NET s'appuie sur l'API Windows. Vous pouvez appeler directement l'API Windows mais ses arguments sont si larges, complexes et méthodes si vastes que vous pouvez facilement faire des erreurs / bugs / 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.

Je voudrais aborder un aspect particulier de cette question, tel qu'il ressort de ce commentaire:

OAuth: avant d'accorder l'accès à certaines fonctionnalités, l'authentification doit être effectuée, non?. donc OAuth = qu'est-ce qu'OpenId + accorde l'accès à certaines fonctionnalités? - Hassan Makarov 21 juin à 1h57

Oui et non. La réponse est subtile, alors soyez indulgent avec moi.

Lorsque le flux OAuth vous redirige vers un service cible (le fournisseur OAuth, c'est-à-dire), il est probable que vous devrez vous authentifier auprès de ce service avant qu'un jeton ne soit renvoyé à l'application / au service client. Le jeton résultant permet alors à l'application client de faire des demandes au nom d'un utilisateur donné.

Notez la généralité de cette dernière phrase: spécifiquement, j'ai écrit "au nom d'un utilisateur donné", pas "au nom de vous ". C'est une erreur courante de supposer que «avoir la capacité d'interagir avec une ressource appartenant à un utilisateur donné» implique «vous et le propriétaire de la ou des ressources cibles êtes une seule et même personne».

Ne commettez pas cette erreur.

Bien qu'il soit vrai que vous vous authentifiez auprès du fournisseur OAuth (par exemple, par nom d'utilisateur et mot de passe, ou peut-être des certificats client SSL ou d'autres moyens), ce que le client obtient en retour ne doit pas nécessairement être considéré comme une preuve d'identité. Un exemple serait un flux dans lequel l'accès aux ressources d'un autre utilisateur vous a été délégué (et par proxy, 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 qui capture (à mon avis) les points les plus saillants concernant OpenID Connect (à partir de https://oauth.net/articles/authentication/ ):

OpenID Connect est une norme ouverte publiée début 2014 qui définit une manière interopérable d'utiliser OAuth 2.0 pour effectuer l'authentification des utilisateurs. En substance, c'est une recette largement publiée pour le fondant au chocolat qui a été essayée et testée par un grand nombre et une variété d'experts. Au lieu de créer un protocole différent pour chaque fournisseur d'identité potentiel, une application peut communiquer un protocole à autant de fournisseurs qu'ils souhaitent travailler. Puisqu'il s'agit d'un standard ouvert, OpenID Connect peut être mis en œuvre 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é à côté (ou au-dessus) d'une infrastructure OAuth. OpenID Connect utilise également la suite de spécifications JSON Object Signing And Encryption (JOSE) pour transporter des informations signées et chiffrées à différents endroits. En fait, un déploiement OAuth 2.0 avec des capacités JOSE est déjà un long chemin pour définir un système OpenID Connect 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 bon nombre des pièges discutés ci-dessus en ajoutant plusieurs composants clés à la base OAuth: [...]

Le document décrit ensuite (entre autres) les ID de jeton et un point de terminaison UserInfo. Le premier fournit un ensemble de revendications (qui vous êtes, lorsque le jeton a été émis, etc., et éventuellement une signature pour vérifier l'authenticité du jeton via une clé publique publiée sans avoir à demander au service en amont), et le second fournit un moyen, par exemple, de demander le nom / prénom de l'utilisateur, son e-mail et des informations similaires, le tout de manière standardisée (par opposition aux extensions ad hoc d'OAuth que les gens utilisaient avant les choses standardisées d'OpenID Connect).

Les deux protocoles ont été créés pour différentes raisons. OAuth a été créé pour autoriser des tiers à accéder aux ressources. OpenID a été créé pour effectuer une 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 entraîne un jeton. Le tiers peut utiliser ce jeton pour accéder aux ressources au nom 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 n'a pas connaissance de l'existence de ressources ou d'applications qui doivent être protégées. C'est la principale différence entre OAuth et OpenID.

OpenID Connect étend le protocole d'autorisation OAuth 2.0 pour l'utiliser comme protocole d'authentification, afin que vous puissiez vous connecter à l'aide d'OAuth. OpenID Connect introduit le concept d'un jeton d'ID, qui est un jeton de sécurité qui permet au client de vérifier l'identité de l'utilisateur

OAuth 2.0 est un protocole de sécurité. Il ne s'agit NI d'un protocole d'authentification NI d'un protocole d'autorisation.

L'authentification par définition répond à deux questions.

1. Qui est l'utilisateur?
2. L'utilisateur est-il actuellement présent sur le système?

OAuth 2.0 possède les types de subventions suivants

• client_credentials: lorsqu'une application doit interagir avec une autre application et modifier les données de plusieurs utilisateurs.
• code_autorisation: l'utilisateur délègue le serveur d'autorisation pour émettre un jeton d'accès que le client peut utiliser pour accéder à la ressource protégée
• refresh_token: lorsque le access_token expire, le jeton d'actualisation peut être utilisé pour obtenir un nouveau access_token
• mot de passe: l'utilisateur fournit ses informations de connexion à un client qui appelle le serveur d'autorisation et reçoit un access_token

Tous les 4 ont une chose en commun, access_token, un artefact qui peut être utilisé pour accéder aux ressources protégées.

Le 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 en action, publications Manning)

Parlons du chocolat. Nous pouvons faire de nombreuses confiseries à partir de chocolat, y compris le fudge, la crème glacée et le gâteau. Mais, aucun de ceux-ci ne peut être assimilé au chocolat car plusieurs autres ingrédients tels que la crème et le pain sont nécessaires pour faire 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 qui sont nécessaires pour fournir la fonctionnalité "Authentification".

Si vous voulez l'authentification, vous pouvez opter pour OpenID Connect, qui fournit un "id_token", à part un access_token, qui répond aux questions auxquelles chaque protocole d'authentification doit répondre.

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