Que signifie l’authentification unique ?

L'authentification unique SSO signifie que dans plusieurs systèmes d'applications, les utilisateurs n'ont besoin de se connecter qu'une seule fois pour accéder à tous les systèmes d'applications mutuellement fiables. C'est l'une des solutions d'intégration commerciale d'entreprise. Ses avantages : 1. Améliorer. Efficacité des utilisateurs ; 2. Améliorer l’efficacité des développeurs ; 3. Simplifier la gestion.

Au tout début, une entreprise pouvait n'avoir qu'un seul serveur, mais peu à peu, le nombre de serveurs a commencé à augmenter. Chaque serveur doit être enregistré et connecté, et lors de la déconnexion, il faut se déconnecter un par un. L'expérience utilisateur est très mauvaise ! Vous pouvez imaginer qu'aller à Douban et se connecter à Douban FM, Douban Reading, Douban Movies, Douban Diary... ça va vraiment faire s'effondrer les gens. Nous voulons une autre expérience de connexion : les services d'une entreprise ne nécessitent qu'une seule inscription, une seule connexion lors de la connexion et une déconnexion lors de la déconnexion. Comment faire ?

Inscrivez-vous une fois. Il n'est pas difficile de s'inscrire une fois. Pensez-y, s'agit-il simplement de synchroniser les informations des utilisateurs entre les serveurs ? Oui, mais cette description n'est pas complète. Nous l'expliquerons en détail plus tard lorsque nous parlerons de l'enregistrement des utilisateurs. En fait, la gestion des informations des utilisateurs est la vraie difficulté du SSO. Mais en tant que débutant, notre difficulté réside dans la technologie pour mettre en œuvre le SSO ! Discutons d’abord des moyens de mise en œuvre.

Une connexion et une déconnexion. En repensant à l'histoire des centres commerciaux ordinaires, quel est l'élément clé pour rester connecté ? Enregistreur (session) ? Ce genre de papier qu'on appelle un cookie ? L'identifiant inscrit sur le papier ? Ce sont les informations enregistrées lors de la session et les cookies ne sont pas seulement un outil d'enregistrement des identifiants. Le client détient l'ID et le serveur détient la session, et les deux sont utilisés ensemble pour maintenir l'état de connexion. Le client doit utiliser l'ID comme identifiant et le serveur doit utiliser la session pour vérifier la validité de l'ID (l'ID peut avoir expiré, il peut être falsifié et les informations correspondantes sont introuvables, le client correspondant à l'ID n'a pas encore effectué de vérification de connexion, etc. ). Cependant, la session est unique à chaque serveur au début. Douban FM a sa propre session, Douban Reading a sa propre session et le cookie qui enregistre l'ID ne peut pas être cross-domain. Par conséquent, si nous voulons nous connecter et nous déconnecter une fois, il nous suffit de trouver un moyen de permettre à chaque serveur de partager les mêmes informations de session afin que le client puisse conserver cet identifiant sous chaque nom de domaine. Pour aller plus loin, tant que chaque serveur obtient le même identifiant, il existe un moyen de vérifier la validité de l'identifiant et d'obtenir les informations utilisateur correspondant à l'identifiant, c'est-à-dire qu'il peut vérifier l'identifiant

Méthode de mise en œuvre de l'authentification unique

côté serveur

En fonction de la façon dont le groupe de serveurs génère et vérifie les identifiants, elle est grossièrement divisée en deux types :

"Cookie partagé" est Pour la méthode de partage de session mentionnée ci-dessus, je pense qu'il est préférable de l'appeler "session partagée". En substance, le cookie est simplement un support pour stocker l'identifiant de session, et l'identifiant de session peut également être placé dans l'URL de chaque requête. On dit que cette méthode n’est pas sûre, je ne l’ai donc pas abordée en détail. Quelqu’un peut-il me recommander des informations pertinentes que je vais ajouter plus tard ? En fait, c'est le cas. Après tout, le mécanisme de session est un serveur pour chaque session depuis le début. C'est en effet un peu étrange de supprimer la session et de laisser tous les serveurs la partager.

La méthode SSO-Token n'est pas sûre car c'est une méthode de partage de sessions, nous n'utilisons donc plus l'identifiant de session comme identifiant. Nous générons un autre identifiant et le nommons SSO-Token (ou Ticket). Cet identifiant est unique à l'ensemble du groupe de serveurs, et tous les groupes de serveurs peuvent vérifier le jeton et obtenir les informations de l'utilisateur derrière le jeton. Ce dont nous allons discuter est également de cette façon, et l'organigramme spécifique sera présenté plus tard.

Côté navigateur

La connexion unique comporte toujours une étape très critique. Cette étape n'a rien à voir avec la manière de vérifier le jeton côté serveur. est toujours la méthode "token" actuelle, l'identifiant d'identité sera confronté à un tel problème du côté du navigateur : une fois que l'utilisateur s'est connecté avec succès et a obtenu le jeton (ou l'identifiant de session), comment le navigateur peut-il le stocker et le partager avec d'autres des noms de domaine ? Le même nom de domaine est très simple. Stockez le jeton dans le cookie et définissez le chemin du cookie sur le nom de domaine de premier niveau afin que tous les sous-domaines puissent lire le jeton dans le cookie. Voici comment partager des cookies (c'est ce qu'on appelle des cookies partagés, celui ci-dessus devrait être appelé session partagée). Par exemple : Google, google.com est son nom de domaine de premier niveau, mail.google.com pour les services de messagerie et map.google.com pour les services de cartographie sont tous deux ses sous-domaines. Mais que devons-nous faire lorsque nous passons à plusieurs domaines ? Google possède également un nom de domaine, youtube.com, qui fournit des services vidéo.

Tutoriel recommandé : "

PHP"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!