Une analyse approfondie de la méthode d'implémentation de l'authentification unique SSO en PHP

SSO existe 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. Alors, comment implémenter l’authentification unique SSO en PHP ? L'article suivant vous donnera une introduction détaillée à la mise en œuvre de l'authentification unique SSO.

SSO (Single Sign On), c'est-à-dire l'authentification unique, est une sorte d'autorisation d'accès qui contrôle plusieurs systèmes liés mais indépendants. Les utilisateurs disposant de cette autorisation peuvent utiliser un seul identifiant et un seul mot de passe pour accéder à un certain ou. Plusieurs systèmes pour éviter d'utiliser des noms d'utilisateur ou des mots de passe différents, ou une configuration pour se connecter de manière transparente à chaque système.

Pour les grands systèmes, l'utilisation de l'authentification unique peut éviter bien des problèmes aux utilisateurs. Prenez Baidu par exemple. Il existe de nombreux sous-systèmes sous Baidu - Baidu Experience, Baidu Knows, Baidu Library, etc. Si nous utilisons ces systèmes, chaque système nous demande de saisir un nom d'utilisateur et un mot de passe pour nous connecter une fois. l'expérience va certainement chuter.

Deux éléments qui interagissent avec le SSO : 1. Utilisateur, 2. Système, ses caractéristiques sont : Une connexion, tous les accès. SSO est un type de contrôle d'accès qui contrôle si les utilisateurs peuvent se connecter, c'est-à-dire vérifie l'identité de l'utilisateur, et toutes les autres authentifications du système sont effectuées ici. En regardant le SSO à partir de l'ensemble du système, son noyau est constitué de ces trois éléments : 1. . Utilisateur, 2. Système, 3. Centre d'authentification.

1. Comment effectuer une authentification unique pour le même domaine mais des sous-domaines différents

Supposons que notre site soit déployé selon le nom de domaine suivant :

• sub1.onmpw.com
• sub2.onmpw .com

Ces deux sites partagent le même domaine onmpw.com.

Par défaut, le navigateur enverra le cookie à l'hébergeur correspondant au domaine auquel il appartient. En d'autres termes, le domaine par défaut pour les cookies de sub1.onmpw.com est .sub1.onmpw.com. Par conséquent, sub2.onmpw.com ne recevra aucune information sur les cookies appartenant à sub1.onmpw.com. Parce qu’ils se trouvent sur des hôtes différents et que leurs sous-domaines sont également différents.

1.1 Définissez les informations des cookies des deux sous le même domaine

• Connectez-vous au système sub1.onmpw.com
• Après une connexion réussie, un jeton d'identification unique est généré (connaissant le jeton, vous saurez quel l'utilisateur est connecté). Définir les informations sur le cookie. Il convient de noter ici que le jeton est stocké dans le cookie, mais lors de sa configuration, le domaine auquel appartient ce cookie doit être défini sur le domaine de premier niveau .onmpw.com. La fonction setcookie peut être utilisée ici. Le quatrième paramètre de cette fonction est utilisé pour définir le domaine du cookie.

setcookie(‘token’, ’xxx’, '/', ’.onmpw.com’);复制代码

• Accédez au système sub2.onmpw.com et le navigateur enverra le jeton d'information contenu dans le cookie au système sub2.onmpw.com avec la demande. À ce stade, le système vérifiera d'abord si la session est connectée. Sinon, il vérifiera le jeton dans le cookie pour obtenir une connexion automatique.

• sub2.onmpw.com Écrivez les informations de session après une connexion réussie. Pour une vérification future, utilisez simplement vos propres informations de session pour les vérifier.

1.2 Déconnexion

Il y a un problème ici, c'est qu'après la déconnexion du système sub1, il peut effacer ses propres informations de session et les informations de cookie du domaine .onmpw.com. Il n'efface pas les informations de session du système sub2. Ce sub2 est toujours connecté. En d’autres termes, même si cette méthode permet d’obtenir une authentification unique, elle ne peut pas permettre une déconnexion simultanée. La raison en est que bien que sub1 et sub2 puissent partager des cookies via la configuration de la fonction setcookie, leurs identifiants de session sont différents, et cet identifiant de session est également stocké sous la forme d'un cookie dans le navigateur, mais le domaine auquel il appartient n'est pas .onmpw. .com.

Alors comment résoudre ce problème ? Nous savons que dans ce cas, tant que le sessionId des deux systèmes est le même, ce problème peut être résolu. En d’autres termes, le domaine auquel appartient le cookie stockant sessionId est également .onmpw.com. En PHP, sessionId est généré après l'appel de session_start(). Si vous souhaitez que sub1 et sub2 aient le même sessionId, vous devez définir le domaine auquel appartient le sessionId avant session_start() :

ini_set('session.cookie_path', '/');
ini_set('session.cookie_domain', '.onmpw.com');
ini_set('session.cookie_lifetime', '0');复制代码

• 1 Grâce aux étapes ci-dessus, vous pouvez obtenir une authentification unique et une déconnexion de différents. noms de domaine de deuxième niveau.
• 2. Cependant, cela peut être davantage simplifié. Si le sessionId est le même, une connexion et une déconnexion uniques de différents noms de domaine de deuxième niveau peuvent être réalisées.
• Article de référence : https://www.onmpw.com/tm/xwzj/network_145.html

2. Comment implémenter l'authentification unique entre différents domaines - CAS

Supposons que nous devions utiliser le sites suivants Pour obtenir une authentification unique entre

• www.onmpw1.com
• www.onmpw2.com
• www.onmpw3.com

La solution ci-dessus ne fonctionnera pas.

Il existe actuellement une solution SSO open source sur github. Le principe de mise en œuvre est similaire à celui du SSO grand public : https://github.com/jasny/sso

Principe de base :

• 1. Le client accède à différents sous-systèmes et le centre de service utilisateur SSO correspondant au sous-système utilise le même SessionId.
• 2. Le courtier et le serveur du sous-système sont liés au lien d'autorisation via une pièce jointe.

Le même nom de domaine racine ne spécifie pas le nom de domaine racine du domaine. La première autorisation doit être transmise au service d'autorisation à chaque fois. mais le domaine est spécifié, tant que l'un des mêmes noms de domaine racine est autorisé avec succès, ils peuvent tous partager ce cookie. Il n'est pas nécessaire d'autoriser à nouveau la prochaine fois et les informations utilisateur peuvent être demandées directement.

Première visite A :

Deuxième visite B :

2.1 Jugement du statut de connexion

Après la connexion de l'utilisateur au centre de certification, un établissement est effectué entre l'utilisateur et le centre de certification Une session est démarrée, nous appelons cette session session globale. Lorsque l'utilisateur accède ensuite à l'application système, il nous est impossible d'aller au centre d'authentification pour déterminer s'il faut se connecter à chaque demande d'application. Ceci est très inefficace et c'est quelque chose qu'une seule application Web n'a pas besoin de prendre en compte.

Nous pouvons établir une session locale entre l'application système et le navigateur de l'utilisateur. La session locale maintient le statut de connexion du client et l'application système est dépendante de la session globale. la session locale doit disparaître.

Lorsqu'un utilisateur accède à une application, il détermine d'abord si la session locale existe. Si elle existe, elle est considérée comme connectée, et il n'est pas nécessaire de se rendre au centre d'authentification pour le déterminer. S'il n'existe pas, sera redirigé vers le centre d'authentification pour déterminer si la session globale existe Si elle existe, l'application sera notifiée, et l'application et le client établiront une session locale entre eux la prochaine fois. la demande est demandée, elle n'ira pas au centre d'authentification Vérifié.

2.2 Quitter

Si l'utilisateur quitte un système et accède à d'autres sous-systèmes, il doit également être dans l'état de sortie. Pour ce faire, en plus de mettre fin à la session partielle locale, l'application doit également informer le centre d'authentification de la sortie de l'utilisateur.

Lorsque le centre d'authentification reçoit la notification de sortie, il peut mettre fin à la session globale. Lorsque l'utilisateur accède à d'autres applications, l'état de déconnexion sera affiché.

La nécessité de notifier immédiatement tous les sous-systèmes qui ont établi des sessions locales et de détruire leurs sessions locales peut être déterminée en fonction du projet réel.

Apprentissage recommandé : "Tutoriel vidéo 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!