OpenID Connect a une spécification , il y a des tutoriels, des articles sur le hub et non sur le hub Il est plutôt inutile de sculpter une autre instruction étape par étape, menant de la confusion profonde au travail en passant par l'autorisation et l'authentification. La tâche du texte ci-dessous est différente, pour décrire les idées sous-jacentes aux spécifications (il y en a plusieurs).
Je ne vais pas sauter immédiatement sur le sujet de l'article, mais je vais commencer par des choses simples et beaucoup évidentes. Je vais continuer avec la façon dont ils se sont développés et ce qu'ils ont emballé selon les exigences des clients. Je vais l'aborder historiquement, c'est-à-dire de la manière même dont il est né.
1.
La tâche minimale est simplement de ne laisser personne accéder à aucune de ses ressources. Nous le fermons avec un nom d'utilisateur / mot de passe, qui sait que la bonne paire de noms d'utilisateur et de mots de passe arrivera à la ressource, qui ne le fait pas - non. Cette chose est appelée authentification , car vous pouvez utiliser non seulement des connexions avec des mots de passe (code SMS, par exemple, ou une clé USB matérielle), mais ces détails ne sont pas essentiels pour notre sujet. Je vais également omettre le paragraphe obligatoire sur le danger de transmettre des mots de passe sur Internet sous une forme ouverte, pour laquelle nous n'aimons pas tous l' authentification d'accès de base .
Mieux vaut noter ceci: aucun des utilisateurs n'aime entrer des identifiants avec des mots de passe. Les codes SMS ne sont pas meilleurs et les clés USB sont tout simplement détestées. Afin de ne pas forcer l'utilisateur à entrer une connexion avec un mot de passe pour chaque demande, le serveur en réponse leur envoie une ligne de charabia appelée clé de session . Et puis cette clé s'accroche à chaque demande de serveur par le client (généralement avec un en-tête HTTP, mais ce n'est pas essentiel), et le serveur vérifie s'il a une telle session.
Session avec une clé - les phénomènes, par définition, sont temporaires, le nombre d'or pour la durée de vie d'une session est d'environ "lorsque l'onglet du navigateur est ouvert, mais pas plus d'une journée"
2.
Ils ont laissé entrer n'importe qui - c'est bien. Maintenant, vous devez comprendre exactement qui nous lâchons. Et non seulement pour déduire ce qu'il a entré comme nom dans le coin supérieur droit, mais aussi pour décider quoi le laisser entrer et quoi ne pas le faire.
Et tout cela s'appelle - autorisation . Et je ne suis pas sûr de vous, mais je le confond tout le temps avec l'authentification. Afin de ne pas confondre - une règle relativement mnémonique, "autorisation" - avec les mots "auteur", "auteur", ils écrivent sur les couvertures de livres, et ils n'y écrivent jamais "un membre valide de l'Union des écrivains". Un auteur est toujours une personne très spécifique. L'autorisation est donc un processus lorsque nous comprenons qui nous avons exactement lancé par identifiant et mot de passe.
3.
Ok Nous avons un site, il y a quelque chose de secret sur le site, à l'entrée de la partie secrète nous avons besoin d'un mot de passe, chacun ne montre que ses secrets, et nous ne montrons pas d'étrangers. La vie ne s'arrête pas et nous avons un autre site. Et ici, nous rencontrons à nouveau le problème du point 1, personne n'aime entrer les noms d'utilisateur et les mots de passe! Vous pouvez combiner la base d'utilisateurs et cela leur évitera de devoir s'inscrire deux fois, mais comment les éviter de ressaisir le login et le mot de passe à l'entrée? Étant donné l'existence d'une telle chose que la même politique d'origine (et nos sites sont situés, bien sûr, sur différents domaines, les cookies avec une clé de session ne sont pas visibles pour l'autre)? Ici, pour donner de l'importance au moment, je vais commencer un nouveau point.
4.
SSO , Single Sign On - quelle que soit l'implémentation, Microsoft Kerberos, SAML, ou quelque chose OAuth 2.0 , sur lequel OpenID Connect est construit, à propos duquel je vous écris ici, en fait, sous le capot, il y a toujours la même chose: il y a un serveur séparé autorisation , et toute personne qui souhaite autoriser un utilisateur le redirige. Si l'utilisateur est déjà autorisé, la session est récupérée et il s'envole immédiatement du serveur d'autorisation et obtient où il voulait. S'il n'est pas autorisé, le serveur d'autorisation résout ce problème du mieux qu'il peut, en demandant une connexion avec un mot de passe, en règle générale, et si la solution réussit, il renvoie l'utilisateur.
De plus, SAML pour le moment la solution, pour ainsi dire, est dépassée. Et Kerberos est généralement une magie Microsoft fermée complètement distincte qui va bien au-delà de la portée du protocole HTTP. Eh bien, nous allons nous concentrer là-dessus. Et puis nous arrivons au problème suivant.
Il existe déjà un scénario de travail compréhensible - dans toute situation incompréhensible, envoyez l'utilisateur au serveur d'autorisation, laissez-le décider quoi faire de lui et retournez une réponse toute prête. Mais comment exactement le serveur d'autorisation indique-t-il à cet autre serveur que l'utilisateur est autorisé? Nous revenons ici aux idées du premier paragraphe, à savoir la clé de session. Revenons à l'essentiel: la présence d'une clé de session est un signe d'autorisation, la clé de session elle-même ouvre la porte aux informations utilisateur et, vous ne le croirez pas, aux informations de session. Le serveur d'autorisation autorise et donne donc la clé de session à un autre serveur.
Maintenant, cependant, il n'est plus appelé une clé de session, mais un jeton .
Plus précisément, (selon le protocole OAuth 2.0 , au-dessus duquel OpenID Connect est écrit), ce sont deux jetons à la fois - Access Token , pour l'accrocher à toutes les demandes en tant que clés de session coupées par les grands-pères, et Refresh Token , pour mettre à jour le jeton d'accès quand il s'éteint.
Pour résumer le sous-total. Au lieu de demander à l'utilisateur un nom d'utilisateur et un mot de passe, le serveur les envoie à un autre serveur, un serveur d'autorisation distinct. Il fait tout le travail, puis donne les premiers jetons. Dans exactement ce scénario, les applications sont autorisées, mobiles et parfois de bureau., Elles ne font simplement aucune redirection, elles envoient simplement le serveur d'autorisation JSON avec un nom d'utilisateur et un mot de passe, et il leur envoie des jetons en réponse.
Les applications mobiles et de bureau peuvent le faire. Pour une raison quelconque, ils sont considérés comme plus sûrs que le Web, mais le Web a une vie plus compliquée.
6.
D'une part, ce n'est pas plus compliqué, mais au contraire plus simple. Vous pouvez faire une redirection et ne pas vous soucier de rendre un formulaire de connexion-mot de passe. D'un autre côté, je ne veux vraiment, vraiment pas faire glisser les jetons à travers le navigateur en clair. C'est presque aussi dégoûtant que le mot de passe non chiffré dans l' authentification d'accès de base . Mais personne ne veut répéter cette vieille et terrible erreur.
Il n'y avait pas de solution au problème pour qu'il soit très élégant, mais fonctionnel. Tout d'abord, tout se passe comme d'habitude, en passant à l'autorisation, l'autorisation elle-même. Ensuite, quand vient le temps de revenir avec des jetons, la redirection inverse se produit. Mais au lieu des jetons, un code à usage unique est attaché à l'adresse de retour. Le code à usage unique vient d'être généré par le serveur d'autorisation uniquement pour ce moment particulier. Il a une durée de vie très courte. Ayant à peine reçu un code à usage unique, un autre serveur devrait arracher ses jupes, gonfler ses yeux et se précipiter à nouveau vers le serveur d'autorisation, afin de recevoir les jetons convoités du code à usage unique.
Il existe une ressource spéciale pour un voyage avec un code pour les jetons sur le serveur d'autorisation. Il accepte, par spécification, non GET, mais POST. Cela nous indique en quelque sorte que cette demande doit être faite non pas à partir du navigateur, mais d'un serveur à l'autre.
Pour la même raison, sur tout serveur d'autorisation CORS qui se respecte, les requêtes POST sont interdites.
7.
Au fait, vous souvenez-vous encore de l'authentification et de l'autorisation? L'authentification, c'est quand quelqu'un est simplement autorisé à entrer par login et mot de passe, ou n'est pas autorisé. Et l'autorisation, c'est qu'après avoir déjà démarré, ils commencent à comprendre qui exactement ils ont démarré.
Vous souvenez-vous d' OAuth 2.0 ? Je l'ai mentionné plusieurs fois ci-dessus, comme une sorte de fondation pour OpenID Connect.
Vous souvenez-vous d' OpenID Connect ? Cet article est juste stupide.
Ainsi, OAuth 2.0 est l'authentification. L'ensemble de la procédure légèrement déroutante décrite précédemment avec trois participants, un mot de passe, un code et un jeton est une question d'authentification, qui consiste simplement à faire exécuter quelqu'un quelque part. Protocole OAuth 2.0.
OpenID Connect est une autorisation. C'est-à-dire qu'il ajoute à OAuth les parties où il s'avère qui ils ont lâché.
Pour ce faire, un autre est ajouté à la liste des jetons, il s'appelle ID Token . Ceux qui suivent le lien sont probablement surpris de ne rien voir sur aucun ID de jeton. Que la surprise ne se transforme pas en frayeur, ID Token est le JWT retourné sous forme de poupée imbriquée encodée en base64 dans le même JSON que Access Token et Refresh Token. En tout cas, tout ce que vous vouliez savoir sur l'utilisateur est en lui.
Et il y a aussi une ressource spéciale sur le serveur d'autorisation appelée userinfo, où vous pouvez frapper avec Access Token et obtenir le même JSON en réponse que dans Token ID. Mais pourquoi est-il nécessaire si l'ID de jeton est déjà là? Question aux auteurs de la spécification.
OpenID Connect contient également une description des différents champs d'informations utilisateur. Comment puis-je obtenir ces informations, directement pendant l'autorisation ou à tout moment après. Et une description de comment et quand l'utilisateur vous autorisera à utiliser ces informations.
Ou ne le permettez pas. Donc, en bref, OpenID Connect 1.0 est conçu.
8.
Un petit clinquant dans le protocole. J'espère que vous en avez assez de lire l'article pour le moment, afin de ne pas faire très attention à cet article, juste en le passant dans les yeux. Ici, je mentionnerai les paramètres qui sont dans la spécification, et ils portent une certaine charge sémantique, mais ils ne sont pas directement liés à la mise en œuvre de l'idée elle-même. Fondamentalement, ils ajoutent de la sécurité, ou tout simplement vous permettent de transférer des informations d'un des participants au processus à un autre, si nécessaire.
ID client et secret client . Le client dans la langue du protocole OpenID Connect n'est pas du tout un navigateur, mais le tout autre serveur qui doit autoriser l'utilisateur. Supposons que vous ayez un site Web et que vous souhaitiez y attacher une autorisation à la mode via Facebook. Et par googol. Et pas si à la mode via Twitter. La mise en œuvre du protocole dans le code ne sera pas suffisante. Vous devrez également vous inscrire sur Facebook, sur Google et sur Twitter, mais pas en tant qu'utilisateur, mais en tant que client même qui, en tant que serveur, peut utiliser son autorisation. Lors de votre inscription, vous recevrez un identifiant client et un secret client du facebook conditionnel. Et lorsque vous demandez une autorisation, entre autres, envoyez un identifiant client. Et lorsque vous utilisez un code à usage unique pour un jeton, Client Secret vous demandera également.
Rediriger l'URI . Ici, tout est simple. Lorsque vous envoyez un utilisateur à un Facebook conditionnel pour vous connecter, vous devez indiquer à Facebook où lui retourner les codes et les jetons après l'autorisation. Bien sûr, vous lui donnez toujours votre identifiant client. Mais un URI de redirection séparé vous permet de rediriger après autorisation différents utilisateurs vers différentes pages, par exemple les administrateurs vers le panneau d'administration, et les utilisateurs ordinaires vers leurs pages personnelles. Pratique. De plus, la liste autorisée des URI de redirection possibles spécifiés dans les paramètres du client sur le Facebook conditionnel est une sécurité supplémentaire.
Portée . Il s'agit d'une liste de ce que le serveur veut savoir sur l'utilisateur à partir du serveur d'autorisation. Les valeurs de la liste sont séparées par des espaces, openid doit être obligatoire parmi elles, puis lisez la spécification.
État . Vous vous souvenez du code unique, par lequel les jetons sont émis, comme un ticket dans une file d'attente électronique? Ainsi, l'état est un code, au contraire, si le serveur d'autorisation émet un code vers un autre serveur afin qu'il le renvoie rapidement, cet état donne un autre serveur d'autorisation à ce serveur pour le renvoyer lors de la redirection. Il est nécessaire, si je comprends bien, si un autre serveur a déjà réussi à créer sa propre session afin qu'elle ne soit pas perdue dans toutes ces redirections.
Il existe d'autres paramètres, tels que le type de demande d'autorisation et la durée de vie du jeton, mais pour comprendre pourquoi vous n'en avez pas besoin.
En conclusion. J'espère vraiment qu'une lecture pas trop réfléchie et ciblée du texte ci-dessus vous a aidé à saisir les idées qui sous-tendent certains protocoles de contrôle d'accès modernes. Mais en commençant à mettre en œuvre, ou tout simplement à configurer l'un d'entre eux, ouvrez les spécifications, trouvez un bon tutoriel et suivez attentivement chaque mot et chaque lettre. Et laissez la compréhension des idées éveiller en vous l'intuition. Et intuition, laissez-vous mordre à la couronne chaque fois que vous manquez un paramètre qui n'est pas si important à première vue, ou un réglage, et laissez-le un trou pour les petites mains enjouées et moites.
N'oubliez pas qu'il s'agit de la même sécurité et que ses règles, aussi stupides et dénuées de sens qu'elles puissent paraître, sont écrites dans le sang. Eh bien, peut-être pas avec du sang, ce n'est pas une mesure de sécurité dans la fonderie, après tout, mais l'argent et la réputation sont sûrs, et l'argent et la réputation ne sont pas non plus les choses que vous devriez facilement jeter comme ça.
Merci à JM pour le fait que le texte que vous avez lu était bien meilleur que celui que j'ai écrit.
Bonne chance et n'oubliez pas de renouveler vos certificats à temps.