Différence entre OAUTH, OpenID et OPENID Connect en termes très simples?
Je suis très confus du 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.
OpenID est un protocole pour l'authentification tandis que OAuth est pour 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 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, les approbations pour authentifier les 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 maître des clés dans un grand hôtel; il donne aux employés des 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 pièces); de plus, les clés s'autodétruisent après 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, alors le serveur S peut inférer = que B a authentifié A avant d'accorder la clé d'accès. Donc, certaines personnes utilisent OAuth où elles devraient utiliser OpenID. Ce schéma peut ou non être instructif; mais je pense que cette pseudo-authentification est plus déroutante qu'autre chose. 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 un clé qui ouvre ma chambre, alors je suppose qu'il s'agit d'un vrai employé, au motif que le maître des clés ne lui aurait pas donné une clé qui ouvre ma chambre s'il ne l'était pas.
Termes simples
- OpenID consiste à vérifier l'identité d'une personne (authentification).
- OAuth consiste à accéder aux affaires d'une personne (autorisation).
- OpenID Connect fait les deux .
Les trois permettent à une personne de donner son nom d'utilisateur/mot de passe (ou tout autre mot de passe) à une autorité de confiance plutôt qu'à une application moins fiable.
Plus de détails
Pour comprendre quelque chose, regardez son histoire.
OpenID & OAuth se sont développés sur des pistes parallèles et ont fusionné en 2014 avec 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 de l'utilisateur privé. Alors que OpenID permet à l'autorité de vérifier l'identité d'un utilisateur, OAuth permet à l'autorité d'accorder un accès limité aux informations d'un utilisateur.
OpenID 1. (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.
- App à l'autorité: Est-ce Steve A. Smith?
- L'utilisateur final et l'autorité parlent un instant.
- Autorité à app: Oui, c'est Steve A. Smith.
OpenID 2. (2007) fait de même, mais ajoute un deuxième format d'identité (XRI) et ajoute de la flexibilité à la façon dont la fin l'utilisateur spécifie l'identité et l'autorité.
OpenID Attribute Exchange 1. (2007) étend OpenID 2.0 en permettant à une application de récupérer et de stocker les informations de profil d'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.
- App à l'autorité: Est-ce Steve A. Smith? Oh, et si c'est le cas, récupérez-moi aussi 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 email est [email protected] et son numéro de téléphone est 123-456-7890.
OAuth 1. (2010) permet à un utilisateur final d'accorder à une application un accès limité aux ressources sur un serveur tiers qu'une autorité possède.
- Application pour l'utilisateur final: nous aimerions accéder à vos photos sur un autre serveur.
- L'utilisateur final et l'autorité parlent un instant.
- Autorité d'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 photos d'un utilisateur final.
OAuth 2. (2012) fait la même chose que OAuth 1.0 mais avec un nouveau protocole.
OpenID Connect (2014) combine les fonctionnalités d'OpenID 2.0, d'OpenID Attribute Exchange 1.0 et OAuth 2.0 dans un seul protocole. Il permet à une application d'utiliser une autorité ...
- pour vérifier l'identité de l'utilisateur final,
- pour récupérer les informations de profil de l'utilisateur final, et
- pour avoir un accès limité aux contenus de l'utilisateur final.
Beaucoup de gens visitent encore ce site alors voici un schéma très simple pour l'expliquer
En plus des autres réponses: je pense que beaucoup de confusion vient de l'imprécision, ou du moins utilisation inhabituelle des termes Authentification et Autorisation
OpenID Connect 1.0 est commercialisé comme une solution d'authentification , alors qu'il ne gère pas, en soi, 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é en tant que protocole de fédération , permettant à une partie utilisatrice d'utiliser le processus d'authentification, la base de données utilisateur et la gestion de session existants d'un tiers Fournisseur d'identité. C'est fonctionnellement similaire à SAML 2.0.
Remarque: à strictement 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'identification 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 d'une politique d'accès qui détermine laquelle les utilisateurs ont accès à quelles ressources. Cette définition ne s'applique guère à OAuth.
OAuth 2.0 donne en fait aux utilisateurs un moyen d'autoriser une application/client à accéder à leurs propres ressources en leur nom. En d'autres termes, OAuth 2.0 autorise les clients les applications, et non les utilisateurs, à accéder aux ressources. La politique d'autorisation ( l'octroi aux utilisateurs d'un accès aux ressources) est censé exister avant le déploiement d'OAuth.
J'aurais étiqueté OAuth un protocole de délégation d'accès ).
Je m'excuse si ce message soulève encore plus la confusion :)
Nous avons déjà un diagramme et beaucoup de bonnes données alors voici un exemple au cas où cela aiderait.
Supposons que je souhaite 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 répétitions). 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 local autorisation (par exemple if (user.reputation < 50) throw InsufficientReputationError();)
Pour ce faire, StackOverflow doit d'abord savoir qui fait la 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 sa première demande) mais cela échoue.
Imaginons que StackOverflow ait décidé d'utiliser OpenID Connect. Cela signifie que StackOverflow fait confiance à 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 que c'est 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. Étant donné que 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 avec un serveur d'autorisation auquel Google fait confiance (en réalité, ce serait également Google, mais cela n'a pas à être le cas) et obtenez un jeton d'accès. Il prend ce jeton d'accès à Google et demande l'identité de l'utilisateur. Google retourne ensuite l'identité de l'utilisateur (signature de 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 en utilisant OpenID Connect
- Google a autorisé la demande d'identité de SO en utilisant OAuth
- Le serveur d'autorisation a authentifié StackOverflow (probablement à l'aide d'un identifiant client et d'un secret client).
- De plus, dans le cadre du workflow OAuth, le serveur d’autorisations peut avoir authentifié la demande en demandant à l’utilisateur son nom d'utilisateur et son mot de passe.
- En outre, l'utilisateur lui-même peut avoir autorisé la demande d'identité de SO en répondant à un écran d'autorisation (par exemple "voulez-vous autoriser StackOverflow à accéder à votre email?")
- StackOverflow a autorisé la demande en garantissant à l'utilisateur une réputation> 50.
Qu'est-ce qu'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 Google pour autoriser StackOverflow à accéder à l'identité de l'utilisateur. OpenID avait quelques failles de sécurité (qui, je pense, ont été corrigées) mais à mon avis, le vrai tueur était simplement le fait que OAuth avait un meilleur support et avait donc tendance à être moins de travail que d'apprendre le protocole personnalisé d'OpenID.
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 demande HTTP soit d'abord adressée au serveur d'autorisation pour obtenir un jeton d'accès, puis à nouveau adressée au même serveur pour obtenir un jeton d'identité. Ainsi, une extension a été créée pour la spécification OAuth) pour 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 dérouler entièrement dans le navigateur (par exemple, les serveurs de StackOverflow n'ont pas besoin d'être impliqués). Cependant, ce type d'authentification est moins utile et (je pense?) Est moins couramment utilisé.
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 authentification et autorisation pour différencier Oauth et OpenID est tout simplement fausse. 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 les activités typiques non liées à l'authentification qui sont effectuées, et par qui, dans chaque schéma.
- 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 d'accéder à une adresse Web et, une fois entré, donne à l'application Web sous-jacente un moyen de récupérer des ressources hors site supplémentaires au nom de l'utilisateur.
Pour résumer: OpenID Connect est une API d'identité fédérée qui inclut un profil et une extension de 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 d'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 avant 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, id_tokens et actualiser les jetons. (RFC 6749)
- Configuration: métadonnées du fournisseur publiées sur
.well-known/openid-configuration, y compris l'emplacement des points de terminaison, les algorithmes cryptographiques pris en charge et d'autres informations nécessaires au client pour interagir avec l'OP. (RFC 8414) - Enregistrement client: Endpoint pour 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 réclamations 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 bootstrap Découverte OP fonctionnant en arrière à 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 OAuth WG)