NET 单点登录原理

简介

单点登录是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的保护资源，若用户在某个应用系统中进行注销登录，所有的应用系统都不能再直接访问保护资源，像一些知名的大型网站，如：淘宝与天猫、新浪微博与新浪博客等都用到了这个技术。

原理

单点登录
1. 有一个独立的认证中心，只有认证中心才能接受用户的用户名和密码等信息进行认证，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，当用户提供的用户名和密码通过认证中心认证后，认证中心会创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌即得到了授权，然后创建局部会话。
2. 示例：
  
  下面对上图进行解释：
  1. 当用户还没进行用户登录的时候
    1. 用户去访问系统1的保护资源，系统1检测到用户还没登录，跳转至SSO认证中心，SSO认证中心也发现用户没有登录，就跳转到用户至认证中心的登录页面
    2. 用户在登录页面提交用户相应信息后，认证中心会校验用户信息，如果用户信息正确的话认证中心就会创建与该用户的全局会话（全局会话过期的时候，用户就需要重新登录了。全局会话中存的信息可能有令牌，用户信息，及该在各个系统的一些情况），同时创建授权令牌，然后进行下一步，否则认证中心给出提示（用户信息有误），待用户再次点击登录的时候，再一次进行校验用户信息
    3. 认证中心带着令牌跳转到用户最初请求的地址（系统1），系统1拿到令牌后去SSO认证中心校验令牌是否有效，SSO认证中心校验令牌，若该令牌有效则进行下一步
    4. 注册系统1，然后系统1使用该令牌创建和用户的局部会话（若局部会话过期，跳转至SSO认证中心，SSO认证中心发现用户已经登录，然后执行第3步），返回受保护资源
  2. 用户已经通过认证中心的认证后
    
    用户访问系统2的保护资源，系统2发现用户未登录，跳转至SSO认证中心，SSO认证中心发现用户已经登录，就会带着令牌跳转回系统2，系统2拿到令牌后去SSO认证中心校验令牌是否有效，SSO认证中心返回有效，注册系统2，系统2使用该令牌创建与用户的局部会话，返回受保护资源。
  3. 如果系统1的局部会话存在的话，当用户去访问系统1的保护资源时，就直接返回保护资源，不需要去认证中心验证了
局部会话存在，全局会话一定存在；全局会话存在，局部会话不一定存在；全局会话销毁，局部会话必须销毁

如果在校验令牌过程中发现客户端令牌和服务器端令牌不一致或者令牌过期的话，则用户之前的登录就过期了，用户需要重新登录
单点注销
1. 在一个子系统中注销，全局会话也会被注销，所有子系统的会话都会被注销
2. 示例：
  
  用户向系统1发出注销请求，系统1根据用户与系统1建立的会话id从会话中拿到令牌，向SSO认证中心发起注销请求，认证中心校验令牌有效，会销毁全局会话，同时取出此令牌注册的系统地址，认证中心向所有注册系统发出注销请求，各系统收到注销请求后销毁局部会话，认证中心引导用户跳转值登录页面。
整体陈述
1. 单点登录涉及SSO认证中心与多个子系统，子系统与SSO认证中心需要通信（交换令牌、校验令牌及发起注销请求等），子系统中包含SSO的客户端，SSO认证中心是服务端
2. 认证中心与客户端通信可通过 httpClient、web service、rpc、restful api（url是其中一种）等实现
3. 客户端与服务器端的功能
  1. 客户端：
    1. 拦截子系统未登录用户请求，跳转至sso认证中心
    2. 接收并存储sso认证中心发送的令牌
    3. 与服务器端通信，校验令牌的有效性
    4. 建立局部会话
    5. 拦截用户注销请求，向sso认证中心发送注销请求
    6. 接收sso认证中心发出的注销请求，销毁局部会话
  2. 服务器端：
    1. 验证用户的登录信息
    2. 创建全局会话
    3. 创建授权令牌
    4. 与客户端通信发送令牌
    5. 校验客户端令牌有效性
    6. 系统注册
    7. 接收客户端注销请求，注销所有会话

大致思路是：

访问业务系统时，由自定义的[Authorize]进行拦截

获取到Token设置到请求头进行HttpPost到认证系统提供的/api/token/Authentication接口

响应给业务系统如果是成功则继续访问，如果是失败则401或者跳转到登录页。

具体步骤：

认证中心登录成功后，请求登录中心接口获得token
携带token逐个跳转到业务系统的中转页面。
跳转完成后，返回到认证中心登录页面进行引导。

在 B/S 系统中，登录功能通常都是基于 Cookie 来实现的。当用户登录成功后，一般会将登录状态记录到 Session 中，或者是给用户签发一个 Token，无论哪一种方式，都需要在客户端保存一些信息（Session ID 或 Token ），并要求客户端在之后的每次请求中携带它们。在这样的场景下，使用 Cookie 无疑是最方便的，因此我们一般都会将 Session 的 ID 或 Token 保存到 Cookie 中，当服务端收到请求后，通过验证 Cookie 中的信息来判断用户是否登录。

单点登录（Single Sign On, SSO）是指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的应用系统。举例来说，百度贴吧和百度地图是百度公司旗下的两个不同的应用系统，如果用户在百度贴吧登录过之后，当他访问百度地图时无需再次登录，那么就说明百度贴吧和百度地图之间实现了单点登录。

单点登录的本质就是在多个应用系统中共享登录状态。如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session，比如可以将 Session 序列化到 Redis 中，让多个应用系统共享同一个 Redis，直接读取 Redis 来获取 Session。当然仅此是不够的，因为不同的应用系统有着不同的域名，尽管 Session 共享了，但是由于 Session ID 是往往保存在浏览器 Cookie 中的，因此存在作用域的限制，无法跨域名传递，也就是说当用户在 app1.com 中登录后，Session ID 仅在浏览器访问 app1.com 时才会自动在请求头中携带，而当浏览器访问 app2.com 时，Session ID 是不会被带过去的。实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

实现方式一：父域 Cookie

在将具体实现之前，我们先来聊一聊 Cookie 的作用域。

Cookie 的作用域由 domain 属性和 path 属性共同决定。domain 属性的有效值为当前域或其父域的域名/IP地址，在 Tomcat 中，domain 属性默认为当前域的域名/IP地址。path 属性的有效值是以“/”开头的路径，在 Tomcat 中，path 属性默认为当前 Web 应用的上下文路径。

如果将 Cookie 的 domain 属性设置为当前域的父域，那么就认为它是父域 Cookie。Cookie 有一个特点，即父域中的 Cookie 被子域所共享，换言之，子域会自动继承父域中的Cookie。

利用 Cookie 的这个特点，不难想到，将 Session ID（或 Token）保存到父域中不就行了。没错，我们只需要将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径，这样所有的子域应用就都可以访问到这个 Cookie 了。不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录。

总结：此种实现方式比较简单，但不支持跨主域名。

实现方式二：认证中心

我们可以部署一个认证中心，认证中心就是一个专门负责处理登录请求的独立的 Web 服务。

用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 Token 写入 Cookie。（注意这个 Cookie 是认证中心的，应用系统是访问不到的。）

应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了。如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统。

应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了。

这里顺便介绍两款认证中心的开源实现：

Apereo CAS 是一个企业级单点登录系统，其中 CAS 的意思是”Central Authentication Service“。它最初是耶鲁大学实验室的项目，后来转让给了 JASIG 组织，项目更名为 JASIG CAS，后来该组织并入了Apereo 基金会，项目也随之更名为 Apereo CAS。
XXL-SSO 是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。

总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。

实现方式三：LocalStorage 跨域

前面，我们说实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

父域 Cookie 确实是一种不错的解决方案，但是不支持跨域。那么有没有什么奇淫技巧能够让 Cookie 跨域传递呢？

很遗憾，浏览器对 Cookie 的跨域限制越来越严格。Chrome 浏览器还给 Cookie 新增了一个 SameSite 属性，此举几乎禁止了一切跨域请求的 Cookie 传递（超链接除外），并且只有当使用 HTTPs 协议时，才有可能被允许在 AJAX 跨域请求中接受服务器传来的 Cookie。

不过，在前后端分离的情况下，完全可以不使用 Cookie，我们可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将 LocalStorage 的数据传递给服务端。这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID （或 Token ）放在响应体中传递给前端。

在这样的场景下，单点登录完全可以在前端实现。前端拿到 Session ID （或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中。

传统session和cookie 以及jwt sso 参考

https://blog.csdn.net/weixin_41888813/article/details/102657309