Quand utilisez-vous OpenID vs OpenID Connect
Peuvent-ils être utilisés ensemble? .... ou s'agit-il de deux protocoles distincts qui peuvent être utiles ou non selon le contexte?
La raison pour laquelle je demande, c'est parce que j'essaie de mettre en œuvre ce qui suit:
- L'utilisateur "Bob" accède à un client implémenté en tant qu'application User-Agent uniquement.
- Les ressources protégées sont contrôlées par le même domaine que le serveur d'authentification/autorisation, mais elles se trouvent sur des sous-domaines différents. Cependant, aucune session n'est trouvée dans les cookies, donc ...
Bob clique sur "connexion" et est redirigé vers le serveur d'autorisation/d'authentification en utilisant quelque chose comme ceci:
GET https://accounts.example.com/authorize?response_type=token&client_id=123&redirect_uri=http://original.example.com&scope=openid profile token customBob reçoit une liste d'options parmi lesquelles choisir pour s'authentifier, c'est-à-dire "exemple, google, Twitter", etc., ce qui conduit à son authentification sur example.com, qui à son tour est utilisée pour son autorisation pour une API spécifique hébergée par exemple .com.
Dois-je utiliser OpenID Connect, OpenID 2.0, les deux? Quelle? C'est la première fois que je les implémente. Je ne pose que des questions sur la partie authentification de cela. J'essaie juste de faire authentifier Bob pour que je puisse passer à l'émission du jeton au client.
OpenID et OpenID Connect sont tous deux destinés à l'authentification , pas à l'autorisation . Les deux activités sont distinctes. OpenID Connect est en fait OAuth (un protocole d'autorisation) qui est transformé (abusé) en un protocole d'authentification. Plus d'explications dans cette réponse .
Dans une certaine mesure, vous pouvez mélanger authentification et autorisation, mais c'est une source de confusion. Dans votre cas, vous voulez apparemment authentifier les utilisateurs avec "Google, Twitter, ...": vous voulez que Google (ou Twitter) vous dise qui l'utilisateur est , mais pas ce que l'utilisateur doit être autorisé à faire ; vous voulez ces fournisseurs externes pour l'authentification, pas l'autorisation.
Une autre façon de le voir est la suivante: un utilisateur se connecte à votre serveur [~ # ~] s [~ # ~] . Le serveur [~ # ~] s [~ # ~] offre des "services", c'est-à-dire fera des "choses" quand on le lui demandera; cependant, il n'acceptera pas de faire les mêmes choses pour tout le monde. Supposons que vous avez jugé bon de donner le contrôle de ce que [~ # ~] [~ # ~] peut faire ou non pour chaque utilisateur à un autre système que nous appellerons [~ # ~] r [~ # ~] . [~ # ~] r [~ # ~] peut ou non être le même ordinateur que [~ # ~] s [~ # ~] , mais réfléchissons de manière générique et supposons que [~ # ~] r [~ # ~] est différent de [~ # ~] s [~ # ~] . Du point de vue de [~ # ~] s [~ # ~] , les informations nécessaires sont dans la portée de l'autorisation: [~ # ~] s [~ # ~] veut savoir si l'appel doit être accordé ou non. Il y aura donc un protocole d'autorisation entre [~ # ~] s [~ # ~] et [ ~ # ~] r [~ # ~] . Eventuellement, [~ # ~] s [~ # ~] et [~ # ~] r [~ # ~] ne se parlera pas directement, mais uniquement via des messages ("tickets") transportés par le client; c'est un détail technique.
Cependant, pour décider si une demande donnée à [~ # ~] s [~ # ~] doit être autorisée ou non, le serveur d'autorisation [~ # ~] r [~ # ~] doit savoir qui envoie le demande, car la réponse dépend de l'identité de l'utilisateur. Par conséquent, [~ # ~] r [~ # ~] devra authentifier l'utilisateur; ou, plus généralement, pour parler à un serveur d'authentification [~ # ~] t [~ # ~] . [~ # ~] t [~ # ~] est chargé de s'assurer que l'utilisateur est bien ce qu'il prétend être. Un protocole d'authentification se produit alors entre [~ # ~] r [~ # ~] et [~ # ~] t [~ # ~] .
Dans votre exemple, [~ # ~] r [~ # ~] est votre serveur d'autorisation, tandis que [~ # ~] t [~ # ~] est Google/Twitter. Vous utiliseriez OpenID entre [~ # ~] r [~ # ~] et [~ # ~] t [~ # ~] et OAuth entre [~ # ~] s [~ # ~] et [~ # ~] r [~ # ~] .
OpenID Connect, c'est quand [~ # ~] s [~ # ~] veut aussi faire une authentification; [~ # ~] s [~ # ~] utilise ensuite [~ # ~] r [~ # ~ ] (qui "parle OAuth") et en déduit que si [~ # ~] r [~ # ~] autorise la demande, alors [~ # ~] r [~ # ~] doit avoir effectué une sorte d'authentification de l'utilisateur; donc [~ # ~] s [~ # ~] décide que l'utilisateur est bien ce qu'il prétend être, puisqu'il a (implicitement) convaincu [~ # ~] r [~ # ~] .
Je ne pense pas que les autres réponses précédentes répondent à la question, qui demande la différence entre OpenID Connect et OpenID 2.0. OpenID 2.0 n'est pas OAuth 2.0.
OpenID 2.0 et OpenID Connect sont des normes très différentes avec des paramètres et des formats de corps de réponse complètement différents. Les deux sont construits sur OAuth 2.0 en plaçant des valeurs supplémentaires dans des valeurs par ailleurs valides OAuth 2.0 demandes et réponses, afin de fournir les informations d'identité nécessaires à l'authentification (alors que OAuth 2.0 fournit uniquement l'autorisation, pas l'authentification). OpenID Connect a amélioré la dénomination et la structure de OpenID 2.0 champs et paramètres afin d'être plus facile à utiliser. Je peux facilement lire le OpenID Connect spécification et comprendre à quoi servent toutes les valeurs et à quoi les définir, mais en essayant de lire le OpenID 2.0 la spécification est un peu plus difficile et compliquée.
À ce stade, le choix est facile, OpenID 2.0 est obsolète. Tu devrais utiliser OpenID Connect.
OAuth fournit uniquement et ne doit fournir qu'une autorisation à l'aide d'un jeton d'accès. La connexion OpenID est construite sur OAuth 2 afin de fournir des informations d'authentification des utilisateurs. OpenID connect est en fait l'enfant d'OpenID. Voir OpenID-Connect-Lecture-Lecture-for-MIT, slide
OpenID Connect 1.0 est une simple couche d'identité au-dessus du protocole OAuth 2.0 [RFC6749]. Il permet aux clients de vérifier l'identité de l'utilisateur final en fonction de l'authentification effectuée par un serveur d'autorisation, ainsi que pour obtenir des informations de profil de base sur l'utilisateur final de manière interopérable et de type REST. OpenID Connect Core 1.0 - draft 17
Les choses sont, OpenID connect vous offre un moyen "standard" d'obtenir l'identité de l'utilisateur. Si vous utilisez OAuth et l'API, vous devez adapter votre demande pour chaque ressource, qui peut ne pas toujours fournir les mêmes informations ou changer au fil du temps. Et conceptuellement, vous utilisez OAuth pour être autorisé à utiliser une API, pas pour authentifier un utilisateur.
En arrière-plan, les spécifications OAuth 2.0 Authorization Framework [RFC6749] et OAuth 2.0 Bearer Token Usage [RFC6750] fournissent un cadre général permettant aux applications tierces d'obtenir et utilisent un accès limité aux ressources HTTP. Ils définissent des mécanismes pour obtenir et utiliser des jetons d'accès pour accéder aux ressources mais ne définissent pas de méthodes standard pour fournir des informations d'identité. Notamment, sans profilage OAuth 2.0, il est incapable de fournir des informations sur l'authentification d'un utilisateur final. OpenID Connect Core 1.0 - draft 17
Notez que, OpenID connect fournit un id_token avec quelques informations sur l'utilisateur. Mais si vous voulez l'ensemble des informations, vous avez toujours besoin du access_token pour demander au fournisseur OpenID d'obtenir les informations utilisateur (ce qui me confond la première fois que je le vois). Voir 5.3.1. userinfo request dans le projet