Question:
Différence entre OAUTH, OpenID et OPENID Connect en terme très simple?
user960567
2013-10-29 18:31:05 UTC
view on stackexchange narkive permalink

Je suis très confus avec le jargon difficile disponible sur le Web à propos de OAUTH, OpenID et OPENID Connect. Quelqu'un peut-il me dire la différence avec des mots simples.

Bonne comparaison voir sur https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/
Voir aussi: https://security.stackexchange.com/q/133065/2113
Sept réponses:
#1
+183
Thomas Pornin
2013-10-29 18:52:10 UTC
view on stackexchange narkive permalink

OpenID est un protocole pour l ' authentification tandis que OAuth est pour l' autorisation . L'authentification consiste à s'assurer que le type à qui vous parlez est bien celui qu'il prétend être. L'autorisation consiste à décider ce que ce type doit ê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 fait confiance (au moins, fait confiance pour authentifier les utilisateurs). En effet, le serveur B s'assure que U est bien U, puis dit à A: "ok, c'est le véritable U".

En OAuth, l'autorisation est déléguée: l'entité A obtient de l'entité B un "accès droit "que A peut montrer au serveur S pour obtenir l'accès; B peut ainsi délivrer des clés d'accès temporaires et spécifiques à A sans leur donner trop de puissance. Vous pouvez imaginer un serveur OAuth en tant que maître clé dans un grand hôtel; il donne aux employés les clés qui ouvrent les portes des chambres dans lesquelles ils sont censés entrer, mais chaque clé est limitée (elle ne donne pas accès à toutes les chambres); de plus, les clés s'autodétruisent au bout de quelques heures.

Dans une certaine mesure, l'autorisation peut être abusée en une pseudo-authentification, sur la base que si l'entité A obtient de B une clé d'accès via OAuth, et le montre au serveur S, puis le serveur S peut déduire que B a authentifié A avant d'accorder la clé d'accès. Ainsi, certaines personnes utilisent OAuth là où elles devraient utiliser OpenID. Ce schéma peut être instructif ou non; mais je pense que cette pseudo-authentification est plus déroutante que tout. OpenID Connect fait exactement cela: il abuse 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 qu'il s'agit d'un véritable employé, sur la base que le maître des clés ne lui aurait pas donné une clé qui ouvre ma chambre s'il ne l'était pas.

Grand merci. Pouvez-vous simplement l'expliquer dans le jargon anglais au lieu du jargon serveur. J'aime l'exemple de l'hôtel. Mais pour expliquer l'OPENID (premier paragraphe), vous utilisez le mot Serveur
«Serveur» signifie ici «un ordinateur qui se trouve dans une pièce, attendant que des données transitent par le réseau, puis y répond». C'est à peine _jargon_.
@user960567 à un moment donné, vous ne pouvez pas vraiment distiller davantage les détails ou les idées en changeant de «jargons», en particulier lorsqu'il s'agit de sujets complexes comme l'authentification, l'autorisation ou la délégation.
@ThomasPornin: Ne diriez-vous pas qu'OAuth concerne l'autorisation ET l'authentification? Parce que l'authentification est toujours la base d'une autorisation réussie, n'est-ce pas? Bien que dans votre exemple d'authentification OAuth (au moins dans le type d'autorisation d'autorisation), l'authentification ait lieu sur le serveur de l'entité B où l'autorisation est effectuée sur le serveur S.
@ThomasPornin, Hey expert s'il vous plaît vérifier ceci, il y a beaucoup de confusion là-bas, http://security.stackexchange.com/questions/44843/how-secure-is-redirecting-user-from-http-normal-bank-com-to -https-secure-ban / 44880? noredirect = 1 # 44880
@ThomasPornin, une clé de chambre d'hôtel est analogue à un jeton d'accès / porteur OAuth 2; il n'est pas analogue à un jeton OpenID Connect ID.
Il semble que cette distinction: "OpenID est un protocole pour l'authentification tandis que OAuth est pour l'autorisation" n'est plus valide. Google utilise OAUTH 2.0 pour l'authentification et l'autorisation maintenant (https://developers.google.com/accounts/docs/OAuth2Login)
@GayanSanjeewa Et [maintenant non] (https://developers.google.com/accounts/docs/OpenID#shutdown-timetable).
OK, donc A est le consommateur et B est le fournisseur d'ID. Qu'est-ce que le serveur S?
@BenV en fonction de la page que vous avez liée, Google utilise désormais SEULEMENT la fonctionnalité OAuth 2.0 dans OpenID Connect.Ils ont cessé de prendre en charge OpenID 2.0 au profit d'OAuth 2.0 simplement parce que la dernière version d'OAuth prend en charge OAuth, sans faire comprendre à l'utilisateur les grandes différences apparentes que j'essaie toujours de comprendre.Cela semble suggérer qu'OpenID en soi n'est plus utilisé?
Selon [le lien] (https://developers.google.com/accounts/docs/OpenID#shutdown-timetable) fourni par BenV, OpenID Connect ne prend même plus en charge un protocole OpenID distinct.Au lieu de cela, il s'agit d'une couche de pseudo-authentification entièrement construite sur OAuth 2.0, exigeant que l'utilisateur donne au site l'accès à son ex.Compte Google et permettant aux deux sites de surveiller l'activité des utilisateurs de l'autre.Est-ce vrai??OpenID existe-t-il plus en tant que protocole séparé?
OpenID consiste donc à permettre aux utilisateurs de se connecter à l'aide d'un autre service.OAuth consiste à laisser un serveur faire des choses en votre nom.Droite?Dans un certain sens, ils semblent aller dans des directions opposées.
Excellente explication!J'utilisais OAuth pour m'authentifier.Vous avez sauvé mon homme du jour!
#2
+95
Shaun Luttin
2016-07-19 00:34:13 UTC
view on stackexchange narkive permalink

Termes simples

  1. OpenID consiste à vérifier l ' identité (authentification) d'une personne.
  2. OAuth consiste à accéder à le truc d'une personne (autorisation).
  3. OpenID Connect fait les deux .

Les trois permettent à une personne de donner son nom d'utilisateur / mot de passe (ou autres informations d'identification) à une autorité de confiance plutôt qu'à une application moins fiable.

Plus de détails

Pour comprendre quelque chose, regardez son histoire.

OpenID & OAuth s'est développé sur des pistes parallèles et a fusionné en 2014 dans OpenID Connect. Tout au long de leur histoire, OpenID et OAuth ont laissé une application utiliser une autorité de confiance pour gérer les informations d'identification des utilisateurs privés. Alors qu'OpenID permet à l'autorité de vérifier l'identité d'un utilisateur, OAuth permet à l'autorité d'accorder un accès limité aux éléments d'un utilisateur.

OpenID 1.0 (2006) permet à une application de demander à une autorité la preuve qu'un utilisateur final possède une identité (une URL).

  • Utilisateur final de l'application: je suis Steve A. Smith.
  • Application à l'autorité: s'agit-il de Steve A. Smith?
  • L'utilisateur final et l'autorité parlent au nom un instant.
  • Autorité envers l'application: oui, c'est Steve A. Smith.

OpenID 2.0 (2007) fait de même, mais ajoute un deuxième format d'identité (XRI) et ajoute de la flexibilité à la manière dont l'utilisateur final spécifie l'identité et l'autorité.

OpenID Attribute Exchange 1.0 (2007) étend OpenID 2.0 en permettant à une application d'extraire & les informations de profil de l'utilisateur final avec l'autorité - en plus de vérifier l'identité de l'utilisateur final.

  • Utilisateur final de l'application: Je suis Steve A. Smith.
  • Application à l'autorité: est-ce Steve A. Smith? Oh, et si c'est le cas, récupérez-moi également son adresse e-mail et son numéro de téléphone.
  • L'utilisateur final et l'autorité parlent un instant.
  • Autorité à app: Oui, c'est Steve A. Smith. Son adresse e-mail est [email protected] et son numéro de téléphone est le 123-456-7890.

OAuth 1.0 (2010) permet à un utilisateur final d'accorder à une application un accès limité aux ressources d'un serveur tiers appartenant à une autorité.

  • Application à l'utilisateur final: nous aimerions accéder à vos photos sur un autre serveur.
  • L'utilisateur final et l'autorité parlent un instant.
  • Autorité sur l'application: voici un jeton d'accès.
  • Application sur un serveur tiers: voici le jeton d'accès qui prouve que je suis autorisé à accéder aux images d'un utilisateur final.

OAuth 2.0 (2012) fait la même chose que OAuth 1.0 mais avec un tout nouveau protocole.

OpenID Connect (2014) combine les fonctionnalités d'OpenID 2.0, d'OpenID Attribute Exchange 1.0 et d'OAuth 2.0 dans un seul protocole. Il permet à une application d'utiliser une autorité ...

  1. pour vérifier l'identité de l'utilisateur final,
  2. pour récupérer les informations de profil de l'utilisateur final, et
  3. pour obtenir un accès limité aux informations de l'utilisateur final.
Merci pour cette excellente réponse Shaun.La perspective historique et les scénarios faciles à lire clarifient beaucoup de confusions.
OAuth 2.0 ne fait pas la même chose que OAuth 1.0, car OAuth 1.0 fournit à la fois l'authentification et l'autorisation avant d'utiliser une ressource, tandis que OAuth 2.0 fournit uniquement une autorisation.Dans OAuth 1.0, chaque demande est signée avec une clé partagée secrète pré-négociée entre le client et le serveur et donc chaque demande est authentifiée (en raison du processus de signature) et autorisée (parce que l'utilisateur a autorisé le jeton).Alors qu'avec OAuth 2, cela peut ne pas être le cas - vous pouvez avoir des implémentations où seul le jeton d'accès suffit pour accéder aux ressources (pas d'authentification).
#3
+59
Vrashabh Irde
2014-05-19 13:39:16 UTC
view on stackexchange narkive permalink

Beaucoup de gens visitent encore ceci, alors voici un diagramme très simple pour l'expliquer

OpenID_vs._pseudo-authentication_using_OAuth

Avec l'aimable autorisation de Wikipedia

Pourquoi quelqu'un ne pouvait-il pas récupérer le certificat dans l'authentification OpenID et prétendre être l'utilisateur authentifié?
@ptf Sonne comme une question distincte!
@ptf S'ils peuvent y avoir accès, ils le peuvent bien sûr.Un jeton OAuth et, eh bien, * toute * forme de jeton d'accès peuvent bien sûr être utilisés par un tiers qui y a eu accès d'une manière ou d'une autre.Le serveur a déclaré qu'il pourrait, dans les deux cas, tenter d'appliquer des heuristiques (par exemple, géolocalisation, comportement d'accès) pour affirmer qu'il peut s'agir d'un acteur malveillant et expirer la session ou forcer l'assertion MFA.
#4
+10
Pace
2018-03-13 02:34:12 UTC
view on stackexchange narkive permalink

Nous avons déjà un diagramme et beaucoup de bonnes données, voici donc un exemple au cas où cela pourrait aider.

Disons que je veux publier un commentaire sur StackOverflow. StackOverflow n'autorise les commentaires que si un utilisateur a 50 points de réputation.

StackOverflow doit autoriser cette demande (par exemple, ne l'autoriser que si l'utilisateur a> = 50 rep). StackOverflow n'utiliserait pas OAuth pour ce faire car StackOverflow possède la ressource protégée. Si StackOverflow essayait de publier un commentaire sur Facebook au nom de l'utilisateur, il utiliserait OAuth. Au lieu de cela, StackOverflow utilisera l'autorisation locale (par exemple if (user.reputation < 50) throw InsufficientReputationError (); )

Pour ce faire, StackOverflow doit d'abord savoir qui fait le demande. En d'autres termes, pour autoriser la demande, il doit d'abord authentifier la demande.

StackOverflow vérifie d'abord la session et les en-têtes HTTP pour voir si l'utilisateur peut être rapidement authentifié ( par exemple, ce n'est pas leur première requête) mais cela échoue.

Imaginons que StackOverflow ait décidé d'utiliser OpenID Connect. Cela signifie que StackOverflow approuve un fournisseur d'identité. Il s'agit d'un service approuvé par StackOverflow, qui peut indiquer à StackOverflow qui est l'utilisateur actuel. Dans cet exemple, nous supposerons qu'il s'agit de Google.

StackOverflow demande maintenant à Google qui est l'utilisateur actuel. Cependant, Google doit d'abord s'assurer que StackOverflow est autorisé à savoir qui est l'utilisateur actuel. En d'autres termes, Google doit autoriser StackOverflow. Puisque Google est le propriétaire de la ressource protégée et StackOverflow est celui qui y accède, nous pouvons utiliser OAuth ici. En fait, OpenID Connect l'exige.

Cela signifie que StackOverflow doit s'authentifier auprès d'un serveur d'autorisation en qui Google fait confiance (en réalité, ce serait également Google, mais ce n'est pas forcément le cas) et obtenir un jeton d'accès . Il prend ce jeton d'accès à Google et demande l'identité de l'utilisateur. Google renvoie ensuite l'identité de l'utilisateur (en signant l'identité en cours de route) et StackOverflow autorise ensuite la demande maintenant qu'il connaît l'identité de l'utilisateur.

Au cas où vous l'auriez manqué, il y avait plusieurs étapes d'authentification et d'autorisation chacune.

  • StackOverflow a tenté d'authentifier la demande à l'aide de cookies de session, mais cela a échoué.
  • StackOverflow a ensuite authentifié la demande à l'aide de OpenID Connect
  • Google a autorisé la demande d'identité du SO en utilisant OAuth
  • Le serveur d'autorisation authentifié StackOverflow (probablement à l'aide d'un identifiant client & client secret).
  • De plus, dans le cadre du workflow OAuth, le serveur d’autorisation peut avoir authentifié la demande en demandant à l’utilisateur son nom d’utilisateur, le mot de passe &.
  • En outre, l'utilisateur elle-même peut avoir autorisé la demande d'identité de l'OS en répondant à une subvention écran (par ex. "voulez-vous autoriser StackOverflow à accéder à votre messagerie?")
  • StackOverflow a autorisé la demande en s'assurant que l'utilisateur avait> 50 points de réputation.

Qu'est-ce que OpenID (sans la connexion)?

Il s'agissait d'un protocole antérieur qui permettait à un fournisseur d'identité (comme Google) de transmettre des informations utilisateur à un service (comme StackOverflow). Cependant, il a utilisé une autre méthode (pas OAuth) pour que Google autorise StackOverflow à accéder à l'identité de l'utilisateur. OpenID avait quelques failles de sécurité (qui, je crois, ont été corrigées) mais à mon avis, le vrai tueur était simplement le fait qu'OAuth avait un meilleur support et avait donc tendance à être moins de travail que l'apprentissage du protocole personnalisé d'OpenID.

Depuis aujourd'hui, tout le monde l'abandonne. Ne l'utilisez pas. Utilisez OpenID Connect.

"Abuser" d'OAuth

Dans le scénario que j'ai décrit ci-dessus, OAuth est utilisé exactement comme prévu pour l'autorisation. Cependant, il existe un autre flux de travail qui peut souvent dérouter les gens. Cela est dû au fait que dans de nombreuses situations (la plupart?), Le serveur fournissant l'identité de l'utilisateur et le serveur d'autorisation OAuth sont le même serveur.

Dans ce cas, il semble un peu excessif qu'une requête HTTP soit d'abord adressée au serveur d'autorisation pour obtenir un jeton d'accès, puis à nouveau sur le même serveur pour obtenir un jeton d'identité. Ainsi, une extension a été créée pour la spécification OAuth afin de permettre au serveur d'autorisation de regrouper les informations d'identité de l'utilisateur avec le jeton d'accès.

Cela permet à l'authentification de se produire entièrement dans le navigateur (par exemple, StackOverflow's les serveurs n'ont pas besoin d'être impliqués). Cependant, ce type d'authentification est moins utile et (je pense?) Est moins couramment utilisé.

+1 pour expliquer la partie "Qu'est-ce que OpenID (sans la connexion)?"
#5
+8
Guillaume
2017-08-07 21:09:49 UTC
view on stackexchange narkive permalink

En plus des autres réponses: je pense que beaucoup de confusion vient de l’utilisation inexacte, ou du moins inhabituelle des termes Authentification et Autorisation

OpenID Connect 1.0 est commercialisé comme une solution d ' Authentification , alors qu'il ne gère pas à lui seul l'authentification. L'authentification "réelle" dans son sens de base (processus de validation des informations d'identification de l'utilisateur pour prouver une identité ) est hors de portée d'OpenID Connect.

OpenID Connect devrait être mieux commercialisé comme un protocole de Fédération , permettant à une partie de confiance d'utiliser le processus d'authentification existant, la base de données utilisateur et la gestion de session d'un fournisseur d'ID tiers. C'est fonctionnellement similaire à SAML 2.0.

Remarque: à proprement parler, du point de vue de la partie utilisatrice, l'obtention et la validation d'un jeton d'identification auprès d'un fournisseur d'identité peuvent être considérées comme une méthode d'authentification. Je crois que c'est de là que vient «OpenID Connect est un protocole d'authentification».


Même raisonnement pour OAuth 2.0 étant un protocole d ' autorisation : généralement l'autorisation est le processus de définition une stratégie d'accès qui détermine quels utilisateurs ont accès à quelles ressources. Cette définition ne s'applique guère à OAuth.

OAuth 2.0 permet en fait aux utilisateurs d'autoriser une application / client à accéder à leurs propres ressources en leur nom. En d'autres termes, OAuth 2.0 autorise les applications clients , et non les utilisateurs, à accéder aux ressources. La politique d'autorisation (accordant aux utilisateurs l'accès aux ressources) est censée exister avant le déploiement d'OAuth.

J'aurais qualifié OAuth de protocole de délégation d'accès .

Je m'excuse si ce message soulève encore plus la confusion :)

Oui, je pensais la même chose.Si nous essayons d'accorder à l'utilisateur l'accès aux ressources, cela devrait être géré différemment car ce n'est pas une délégation comme ce que fait oauth2
#6
+3
johnaweber
2017-08-08 17:42:43 UTC
view on stackexchange narkive permalink

Comme déjà mentionné, Oauth est une chose, OpenID en est une autre et OpenID Connect combine les deux.

Mais, comme déjà mentionné, l'utilisation de l ' authentification et de l' autorisation pour différencier Oauth et OpenID est tout simplement erronée. L'authentification, la confirmation de la véracité de la revendication d'une entité sur une identité stockée, est attribuée à OpenID mais elle fait définitivement partie du processus Oauth. L'autorisation, l'autorisation d'accéder à une ressource ou un conteneur spécifique, est attribuée à Oauth mais elle fait définitivement partie du processus OpenID.

D'après mon expérience, la vraie différence entre Oauth et OpenID peut être vue dans le non typique -activités liées à l'authentification exécutées et par qui, dans le cadre de chaque programme

  • OpenID facilite l'accès des utilisateurs à un conteneur autorisé avec des ressources groupées (par exemple, l'accès au site Web).
  • Oauth facilite l'accès automatisé à une ressource autorisée dans un conteneur (par exemple, les opérations CRUD sur un fichier ou un enregistrement via une API Web).

OpenID Connect permet alors un utilisateur pour accéder à une adresse Web et une fois dedans, donne à l'application Web sous-jacente un moyen de récupérer des ressources supplémentaires hors site au nom de l'utilisateur.

#7
+3
Mike Schwartz
2018-07-09 01:44:47 UTC
view on stackexchange narkive permalink

Pour résumer: OpenID Connect est une API d'identité fédérée qui comprend un profil et une extension d'OAuth 2.0 qui permet à un client (c'est-à-dire une application mobile ou un site Web) de rediriger une personne vers un fournisseur d'identité central pour l'authentification, et permet à cette personne de autoriser la divulgation d'informations à ce client.

Vous devriez lire mon blog OAuth vs SAML vs OpenID Connect : https://gluu.co/oauth- saml-openid

L'API OpenID Connect comprend un certain nombre de points de terminaison, qui ne sont pas tous liés à OAuth:

Points de terminaison OAuth

  • Autorisation : site Web du canal frontal qui affiche la page de connexion et la page d'autorisation (consentement). (RFC 6749)
  • Token : point de terminaison du canal arrière, nécessitant normalement une authentification, où un client peut demander des jetons d'accès, des id_tokens et des jetons d'actualisation. (RFC 6749)
  • Configuration : métadonnées du fournisseur publiées sur .well-known / openid-configuration , y compris l'emplacement des points de terminaison, algorithmes cryptographiques pris en charge, et d'autres informations dont le client a besoin pour interagir avec l'OP. (RFC 8414)
  • Enregistrement du client : Endpoint d'une application pour créer ou mettre à jour un client OAuth (RFC 7591)

Points de terminaison non OAuth

  • Userinfo : API protégée par jeton d'accès à laquelle le client peut demander des revendications sur un sujet. Il s'agit du serveur de ressources en termes OAuth.
  • JWKS : les clés publiques actuelles de l'OP utilisées pour la signature et le chiffrement
  • Gestion de session : Utilisé par les trois spécifications de déconnexion OpenID (aucune ne fonctionne aussi bien)
  • Webfinger : Utilisé pour amorcer la découverte OP en travaillant à l'envers à partir d'une adresse e-mail (ou d'un autre identifiant), c'est-à-dire comment déterminer le point de terminaison de configuration pour un domaine. (RFC 7033, mais ne fait pas partie du groupe de travail OAuth)
Vous voulez dire, tout ce temps, avec toutes vos réponses, Gluu et OXD sont * vos * produits?Veuillez noter que vous devez divulguer votre relation avec les liens que vous fournissez et en particulier avec les produits que vous référencez.Je crains que chaque référence à Gluu que vous avez publiée soit une "promotion" et puisse être considérée comme une annonce.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...