Webアプリケーションはブラウザ/サーバーアーキテクチャを採用しており、通信プロトコルとしてhttpが使用されます。 http はステートレス プロトコルであり、ブラウザからのすべてのリクエストはサーバーによって独立して処理され、次の図に示されているように、3 つのリクエスト/レスポンス ペア間には接続がありません。
ただし、これは、すべてのユーザーがブラウザを通じてサーバー リソースにアクセスできることも意味します。サーバーの特定のリソースを保護したい場合は、ブラウザ リクエストを制限する必要があり、ブラウザ リクエストを識別して応答する必要があります。合法的なリクエストと無視する; ブラウザリクエストを識別するには、ブラウザリクエストのステータスを知る必要があります。 http プロトコルはステートレスであるため、サーバーとブラウザーが共同して状態を維持できるようにします。これがセッション メカニズムです
2. セッション メカニズム
ブラウザーがサーバーに初めてリクエストするとき、サーバーはセッションを作成し、応答の一部としてセッション ID をブラウザーに送信し、それを保存します。 2 回目は、セッション ID が最初と 3 番目のリクエストに含まれており、サーバーはリクエスト内のセッション ID を取得することで、それが同じユーザーであるかどうかを判断します。このプロセスは次の図に示されています。最初のリクエスト
サーバーはセッション オブジェクト 
をメモリに保存します。ブラウザはセッション ID をどのように保存しますか? 2つの方法が考えられます
サーバーがリクエストを受信すると、自然にパラメータを解析して、セッション ID を取得し、これを使用します。同じセッションからのものであるかどうかを判断することは、明らかに信頼できません。次に、HTTP リクエストが送信されるたびにブラウザがセッション ID を自動的に送信できるようにします。これには Cookie メカニズムが使用されます。 Cookie は、ブラウザーが少量のデータを保存するために使用するメカニズムです。データは、ブラウザーが http リクエストを送信するときに、当然、Cookie 情報
ID」という名前の Cookie が表示されます。これは、Tomcat セッション メカニズムによって維持されるセッション ID です。以下に示すように
セッションメカニズムを使用すると、ブラウザがサーバーに初めてリクエストするときに、ログインステータスを確認するためにユーザー名とパスワードを入力する必要があると想定します。サーバーはユーザー名とパスワードを取得し、データベース内でそれらを比較します。それが正しい場合、そのユーザーは現在正当なユーザーであることを意味し、このセッションは「承認済み」または「ログ記録済み」としてマークされます。 in"など。セッションのステータスなので、当然セッションオブジェクトに保存する必要があります。Tomcatはセッションオブジェクトにログインステータスを次のように設定します
HttpSession session = request.getSession();
session.setAttribute("isLogin", true);HttpSession session = request.getSession();
session.getAttribute("isLogin");モデル
を実装するブラウザリクエストサーバーは下図で説明されています
Web システムは、古代の単一システムから、現在では複数のシステムで構成されるアプリケーション群へと長い発展を遂げてきましたが、ユーザーは 1 つずつログインしなければなりません。その後、1つずつログアウトしますか？下の写真のように
Webシステムは単一のシステムから複数のシステムから構成されるアプリケーション群に発展しました 複雑さはユーザーではなくシステム内で負うべきです。 Web システムが内部的にどれほど複雑であっても、ユーザーにとっては統一された全体です。つまり、ユーザーが Web システムのアプリケーション グループ全体にアクセスすることは、単一のシステムにアクセスするだけで十分です
。
単一システムのログイン ソリューションは完璧ですが、複数システムのアプリケーション グループには適しなくなったのはなぜでしょうか。
単一システムのログイン ソリューションの中核は Cookie であり、Cookie はブラウザとサーバー間のセッション状態を維持するためにセッション ID を保持します。ただし、Cookie には制限があります。この制限は Cookie のドメイン (通常は Web サイトのドメイン名に対応します) であり、ブラウザーが http リクエストを送信すると、すべての Cookie ではなく、そのドメインに一致する Cookie が自動的に送信されます。
この場合、なぜ Web アプリケーション グループ内のすべてのサブシステムのドメイン名を、「*.baidu.com」などの 1 つのトップレベル ドメイン名の下に統一せずに、そのドメイン名を設定することが理論的には可能です。初期の頃でも、多くのマルチシステム ログインでは、同じドメイン名で Cookie を共有するこの方法が使用されていました。
ただし、実現可能だからといってそれが良いというわけではなく、Cookie の共有方法には多くの制限があります。まず第一に、アプリケーション グループのドメイン名を統一する必要があります。次に、アプリケーション グループ内の各システム (少なくとも Web サーバー) で使用されるテクノロジが同じである必要があります。そうでない場合は、Cookie のキー値 (Tomcat の場合は JSESSIONID) が同じである必要があります。 ）が異なり、セッションを維持できず、Java、php、.net システムなどの言語テクノロジ プラットフォームのログイン方法が国境を越えて実装できません。第三に、Cookie 自体が 安全ではありません。
したがって、マルチシステムアプリケーショングループのログインを実現するための新しいログイン方法が必要です。それがシングルサインオンです
シングルサインオンとは何ですか?シングル サインオンの正式名称はシングル サインオン (以下、SSO) です。複数システムのアプリケーション グループ内の 1 つのシステムにログインすると、再度ログインすることなく他のすべてのシステムで認証されることを意味します。シングル サインオンとシングル ログアウトが含まれます。
単一システムのログインと比較して、SSO はユーザーのユーザー名、パスワード、その他のセキュリティ情報を受け入れることができます。ログイン入り口は提供せず、認証センターからの間接的な承認のみを受け入れます。間接認証はトークンを通じて実装され、SSO 認証センターはユーザーのユーザー名とパスワードが正しいことを確認し、次のジャンプ プロセスで認証トークンを各サブシステムに送信し、サブシステムがそのトークンを取得します。つまり、部分セッションの作成が許可されています。部分セッションのログイン方法は、単一システムのログイン方法と同じです。シングル サインオンの原理であるこのプロセスは、次の図で示されています
上の図を以下で簡単に説明します
ユーザーは、システム 1 の保護されたリソースにアクセスします。システム 1 は、ユーザーはログインしておらず、sso 認証センターにジャンプし、自分のアドレスをパラメーターとして使用します
sso 認証センターは、ユーザーがログインしていないことを検出し、ユーザーをログイン ページに誘導します
ユーザーは、ログイン申請を送信するためのユーザー名とパスワード
sso認証センターの検証 ユーザー情報、グローバルセッションと呼ばれるユーザーとSSO認証センター間のセッションを作成し、同時に認可トークンも作成します
SSO 認証センターは、トークンを使用して最初の要求アドレス (システム 1) にジャンプします
システム 1 はトークンを取得し、SSO 認証センターに行き、トークンが有効かどうかを確認します
SSO 認証センターは、システム 1 を登録し、有効として返します
システム 1 は、トークンを使用してユーザーとのセッション (部分セッションと呼ばれます) を作成し、保護されたリソースを返します
ユーザーはシステム 2 の保護されたリソースにアクセスします
システム 2 は、ユーザーがログインしていないことを検出し、SSO 認証センターにジャンプし、自分のアドレスをパラメーターとして使用します
sso 認証センターは、ユーザーがログインしていることを検出し、SSO 認証センターのアドレスにジャンプして戻りますシステム 2 にアクセスし、トークンを添付します
システム 2 はトークンを取得し、sso 認証センターに行き、トークンが有効かどうかを確認します
sso 認証センター トークンを確認し、有効なものを返し、システム 2 を登録します
システム 2 はトークンを使用してユーザーとの部分的なセッションを作成し、保護されたリソースを返します
用户登录成功之后，会与sso认证中心及各个子系统建立会话，用户与sso认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过sso认证中心，全局会话与局部会话有如下约束关系
局部会话存在，全局会话一定存在
全局会话存在，局部会话不一定存在
全局会话销毁，局部会话必须销毁
你可以通过博客园、百度、csdn、淘宝等网站的登录过程加深对单点登录的理解，注意观察登录过程中的跳转url与参数
单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁，用下面的图来说明
sso认证中心一直监听全局会话的状态，一旦全局会话销毁，监听器将通知所有注册系统执行注销操作
下面对上图简要说明
用户向系统1发起注销请求
系统1根据用户与系统1建立的会话id拿到令牌，向sso认证中心发起注销请求
sso认证中心校验令牌有效，销毁全局会话，同时取出所有用此令牌注册的系统地址
sso认证中心向所有注册系统发起注销请求
各注册系统接收sso认证中心的注销请求，销毁局部会话
sso认证中心引导用户至登录页面
单点登录涉及sso认证中心与众子系统，子系统与sso认证中心需要通信以交换令牌、校验令牌及发起注销请求，因而子系统必须集成sso的客户端，sso认证中心则是sso服务端，整个单点登录过程实质是sso客户端与服务端通信的过程，用下图描述
sso认证中心与sso客户端通信方式有多种，这里以简单好用的httpClient为例，web service、rpc、restful api都可以
只是简要介绍下基于java的实现过程，不提供完整源码，明白了原理，我相信你们可以自己实现。sso采用客户端/服务端架构，我们先看sso-client与sso-server要实现的功能（下面：sso认证中心=sso-server）
sso-client
拦截子系统未登录用户请求，跳转至sso认证中心
接收并存储sso认证中心发送的令牌
与sso-server通信，校验令牌的有效性
建立局部会话
拦截用户注销请求，向sso认证中心发送注销请求
接收sso认证中心发出的注销请求，销毁局部会话
sso-server
验证用户的登录信息
创建全局会话
创建授权令牌
与sso-client通信发送令牌
校验sso-client令牌有效性
系统注册
接收sso-client注销请求，注销所有会话
接下来，我们按照原理来一步步实现sso吧！
java拦截请求的方式有servlet、filter、listener三种方式，我们采用filter。在sso-client中新建LoginFilter.java类并实现Filter接口，在doFilter()方法中加入对未登录用户的拦截
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse res = (HttpServletResponse) response;
HttpSession session = req.getSession();
if (session.getAttribute("isLogin")) {
chain.doFilter(request, response);
return;
}
//跳转至sso认证中心
res.sendRedirect("sso-server-url-with-system-url");
}拦截从sso-client跳转至sso认证中心的未登录请求，跳转至登录页面，这个过程与sso-client完全一样
用户在登录页面输入用户名密码，请求登录，sso认证中心校验用户信息，校验成功，将会话状态标记为“已登录”
@RequestMapping("/login")
public String login(String username, String password, HttpServletRequest req) {
this.checkLoginInfo(username, password);
req.getSession().setAttribute("isLogin", true);
return "success";
}授权令牌是一串随机字符，以什么样的方式生成都没有关系，只要不重复、不易伪造即可，下面是一个例子
String token = UUID.randomUUID().toString();
sso认证中心登录后，跳转回子系统并附上令牌，子系统（sso-client）取得令牌，然后去sso认证中心校验，在LoginFilter.java的doFilter()中添加几行
// 请求附带token参数
String token = req.getParameter("token");
if (token != null) {
// 去sso认证中心校验token
boolean verifyResult = this.verify("sso-server-verify-url", token);
if (!verifyResult) {
res.sendRedirect("sso-server-url");
return;
}
chain.doFilter(request, response);
}verify()方法使用httpClient实现，这里仅简略介绍，httpClient详细使用方法请参考官方文档
HttpPost httpPost = new HttpPost("sso-server-verify-url-with-token");
HttpResponse httpResponse = httpClient.execute(httpPost);用户在sso认证中心登录成功后，sso-server创建授权令牌并存储该令牌，所以，sso-server对令牌的校验就是去查找这个令牌是否存在以及是否过期，令牌校验成功后sso-server将发送校验请求的系统注册到sso认证中心（就是存储起来的意思）
令牌与注册系统地址通常存储在key-value数据库（如redis）中，redis可以为key设置有效时间也就是令牌的有效期。redis运行在内存中，速度非常快，正好sso-server不需要持久化任何数据。
令牌与注册系统地址可以用下图描述的结构存储在redis中，可能你会问，为什么要存储这些系统的地址？如果不存储，注销的时候就麻烦了，用户向sso认证中心提交注销请求，sso认证中心注销全局会话，但不知道哪些系统用此全局会话建立了自己的局部会话，也不知道要向哪些子系统发送注销请求注销局部会话
令牌校验成功后，sso-client将当前局部会话标记为“已登录”，修改LoginFilter.java，添加几行
if (verifyResult) {
session.setAttribute("isLogin", true);
}sso-client还需将当前会话id与令牌绑定，表示这个会话的登录状态与令牌相关，此关系可以用java的hashmap保存，保存的数据用来处理sso认证中心发来的注销请求
用户向子系统发送带有“logout”参数的请求（注销请求），sso-client拦截器拦截该请求，向sso认证中心发起注销请求
String logout = req.getParameter("logout");
if (logout != null) {
this.ssoServer.logout(token);
}sso认证中心也用同样的方式识别出sso-client的请求是注销请求（带有“logout”参数），sso认证中心注销全局会话
@RequestMapping("/logout")
public String logout(HttpServletRequest req) {
HttpSession session = req.getSession();
if (session != null) {
session.invalidate();//触发LogoutListener
}
return "redirect:/";
}sso认证中心有一个全局会话的监听器，一旦全局会话注销，将通知所有注册系统注销
public class LogoutListener implements HttpSessionListener {
@Override
public void sessionCreated(HttpSessionEvent event) {}
@Override
public void sessionDestroyed(HttpSessionEvent event) {
//通过httpClient向所有注册系统发送注销请求
}
}以上がシングルサインオンの原則とシンプルな実装の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
