SSO单点登录 - 多系统，单一位置登录，实现多系统同时登录学习笔记

(1)单点登录

多系统的前提下，单一位置的登录，会实现多系统同时登录的一种技术。

常出现在互联网应用和企业级平台中

如：京东

单点登录一般是用于互相授信的系统，实现单一位置登录，全系统有效的。

注意：三方登录：某系统使用其他系统的用户实现本系统登录的方式。这不是单点登录，是解决信息孤岛和用户不对等的实现方案。

(2)Session跨域

所谓Session跨域就是摒弃了系统(tomcat)提供的Session，而使用自定义的类似 Session 的机制来保存客户端数据的一种解决方案。

如：通过设置 cookie 的 domain 来实现 cookie 的跨域传递。在 cookie 中传递一个自定义的 session_id。这个 session_id 是客户端的唯一标记。将这个标记作为 key，将客户端需要保存的数据作为 value，在服务端进行保存（数据库保存或 NoSQL 保存）。这种机制就是 Session 的跨域解决。

什么是跨域：客户端请求的时候，请求的服务器，不是同一个IP，端口，域名，主机号的时候，都称跨域。

什么是域：在应用模型中，一个完整的，有独立访问路径的功能集合称为一个域。如：百度称为一个应用或系统。百度下有若干的域，如搜索引擎(www.baidu.com)，百度贴吧(tie.baidu.com)，百度知道(zhidao.baidu.com)，百度地图(map.baidu.com)等。域信息，有时也称为多级域名。域的划分：以IP，端口，域名，主机名为标准实现划分。

(3)Spring Session共享(了解即可)

spring-session 技术是 spring 提供的用于处理集群会话共享的解决方案。spring-session 技术是将用户 session 数据保存到三方存储容器中，如：mysql，redis 等。

Spring-session 技术是解决同域名下的多服务器集群 session 共享问题的。不能解决跨域 session 共享

使用：配置一个Spring提供的Filter，实现数据的拦截保存，并转换为Spring-session需要的会话对象。必须提供一个数据库的表格信息（由Spring-session提供）。

(4)Nginx Session共享(了解即可)

正向代理：对客户端已知，对服务端透明的代理应用，称为正向代理。如：翻墙软件。

反向代理：对服务端已知，对客户端透明的代理应用，称为反向代理。如：nginx。

nginx：做反向代理服务器，可以为反向代理的服务器集群做集群管理和负载均衡。

Nginx服务器一旦安装，一般提供7*24小时服务。建议安装在服务器中(如：Unix、Linux)

Nginx是一个C语言开发的应用服务器。可以提供的服务有：静态WEB服务，邮件代理服务器，反向代理服务器。

Nginx应用体积非常的小，对CPU和内存的要求也很低。且对负载能力有非常好的体现。核心功能是应用自主开发，很多的附属功能都是借助其它的应用实现的。如：SSL协议的解析-opensll，perl库(正则)的解析-perl包实现。

nginx 中的 ip_hash 技术能够将某个 ip 的请求定向到同一台后端，这样一来这个 ip 下的某个客户端和某个后端就能建立起稳固的 session，ip_hash 是在 upstream 配置中定义的，具体如下：

upstream nginx.example.com
{
	server 127.0.0.1:8080;
	server 127.0.0.1:808;
	ip_hash;
}
server
{
	listen 80;
	location /
	{
		proxy_pass
		http://nginx.example.com;
		proxy_set_header Host $http_host;
		proxy_set_header Cookie $http_cookie;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 100m;
	}
}

ip_hash 是容易理解的，但是因为仅仅能用 ip 这个因子来分配后端，因此 ip_hash 是有缺陷的，不能在一些情况下使用：

nginx 不是最前端的服务器。

ip_hash 要求 nginx 一定是最前端的服务器，否则 nginx 得不到正确 ip，就不能根据 ip 作 hash。譬如使用的是 squid 为最前端，那么 nginx 取 ip 时只能得到 squid 的服务器 ip 地址，用这个地址来作分流是肯定错乱的。

nginx 的后端还有其它方式的负载均衡。

假如 nginx 后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台 session 应用服务器上。

(5)token机制(最常用)

1>传统身份认证

HTTP 是一种没有状态的协议，也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端，客户端使用用户名和密码通过了身份验证，不过下回这个客户端再发送请求时候，还得再验证一下。

解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个Cookie 里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。

上面说的就是 Session，我们需要在服务端存储为登录的用户生成的 Session ，这些 Session 可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。

这种认证中出现的问题是：

Session：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。

可扩展性：在服务端的内存中使用 Session 存储登录信息，伴随而来的是可扩展性问题。

CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用 Ajax 抓取另一个域的资源，就可以会出现禁止请求的情况。

CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

在这些问题中，可扩展性是最突出的。因此我们有必要去寻求一种更有行之有效的方法。

2>Token身份认证

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

客户端使用用户名、密码请求登录

服务端收到请求，去验证用户名、密码

验证成功后，服务端会签发一个Token，再把这个Token 发送给客户端

客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里

客户端每次向服务端请求资源的时候需要带着服务端签发的 Token

服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

使用 Token 验证的优势：

无状态、可扩展

在客户端存储的 Tokens 是无状态的，并且能够被扩展。基于这种无状态和不存储 Session 信息，负载均衡器能够将用户信息从一个服务传到其他服务器上。

安全性

请求中发送 token 而不再是发送 cookie 能够防止 CSRF(跨站请求伪造)。即使在客户端使用 cookie 存储 token，cookie 也仅仅是一个存储机制而不是用于认证。不将信息存储在 Session 中，让我们少了对 session 操作。

(6)Json Web Token(JWT)机制(广泛使用)

JWT 是一种紧凑且自包含的，用于在多方传递 JSON 对象的技术。传递的数据可以使用数字签名增加其安全性。可以使用 HMAC 加密算法或 RSA 公钥/私钥加密方式，即对称加密和非对称加密。

紧凑：数据小，可以通过 URL，POST 参数，请求头发送。且数据小代表传输速度快。

自包含：使用 payload 数据块记录用户必要且不隐私的数据，可以有效的减少数据库访问次数，提高代码性能。

JWT 一般用于处理用户身份验证或数据信息交换。

用户身份验证：一旦用户登录，每个后续请求都将包含 JWT，允许用户访问该令牌允许的路由，服务和资源。单点登录是当今广泛使用 JWT 的一项功能，因为它的开销很小，并且能够轻松地跨不同域使用。

数据信息交换：JWT 是一种非常方便的多方传递数据的载体，因为其可以使用数据签名来保证数据的有效性和安全性。

1.JWT数据结构

JWT 的数据结构是： A.B.C。由字符点 ‘ . ’ 来分隔三部分数据。

A - header 头信息

B - payload （有效荷载，用户的非隐私数据，减少数据库访问）

C - Signature 签名（安全性保证）

1.1header

数据结构： {“alg”: “加密算法名称”, “typ” : “JWT”}

alg 是加密算法定义内容，如：HMAC SHA256 或 RSA

typ 是 token 类型，这里固定为 JWT

1.2payload

可省略，但可省略的仅仅是数据，也就是说它一定有只是可以为空。

在 payload 数据块中一般用于记录实体（通常为用户信息）或其他数据的。主要分为三个部分，分别是：已注册信息（registered claims），公开数据（public claims），私有数据（private claims）。

payload 中常用信息有：iss（发行者），exp（到期时间），sub（主题），aud（受众）等。前面列举的都是已注册信息。

公开数据部分一般都会在 JWT 注册表中增加定义。避免和已注册信息冲突。

公开数据和私有数据可以由程序员任意定义。

注意：即使 JWT 有签名加密机制，但是 payload 内容都是明文记录，除非记录的是加密数据，否则不排除泄露隐私数据的可能。不推荐在 payload 中记录任何敏感数据。

1.3Signature

签名信息。这是一个由开发者提供的信息。是服务器验证的传递的数据是否有效安全的标准。在生成 JWT 最终数据的之前。先使用 header 中定义的加密算法，将 header 和 payload进行加密，并使用点进行连接。如：加密后的head.加密后的 payload。再使用相同的加密算法，对加密后的数据和签名信息进行加密。得到最终结果。

（（A加密）.（B加密））加密 —>C

2.JWT执行流程

借助浏览器，否则JWT流程难以实现。

在这里插入图片描述

(7)基于JWT机制的单点登录

1.实现

https://blog.csdn.net/weixin_51304175/article/details/123964266

重新生成token，就是为了更新token的有效期。

2.注意

使用 JWT 实现单点登录时，需要注意 token 时效性。token 是保存在客户端的令牌数据，如果永久有效，则有被劫持的可能。token 在设计的时候，可以考虑一次性有效或一段时间内有效。如果设置有效时长，则需要考虑是否需要刷新 token 有效期问题。

3.token保存位置

使用 JWT 技术生成的 token，客户端在保存的时候可以考虑 cookie 或 localStorage。cookie 保存方式，可以实现跨域传递数据，但可能会被劫持。localStorage 是域私有的本地存储，无法实现跨域。

4.webstorage

webstorage 可保存的数据容量为 5M。且只能存储字符串数

webstorage 分为 localStorage 和 sessionStorage。

localStorage 的生命周期是永久的，关闭页面或浏览器之后 localStorage 中的数据也不会消失。localStorage 除非主动删除数据，否则数据永远不会消失。

sessionStorage 是会话相关的本地存储单元，生命周期是在仅在当前会话下有效。 sessionStorage 引入了一个“浏览器窗口”的概念，sessionStorage 是在同源的窗口中始终存在的数据。只要这个浏览器窗口没有关闭，即使刷新页面或者进入同源另一个页面，数据依然存在。但是 sessionStorage 在关闭了浏览器窗口后就会被销毁。同时独立的打开同一个窗口同一个页面，sessionStorage 也是不一样的。

(8)Restful接口设计

1.Rest 简述

REST（英文：Representational State Transfer，简称 REST）描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。在目前主流的三种 Web 服务交互方案中，REST 相比于 SOAP（Simple Object Access protocol，简单对象访问协议）以及 XML-RPC 更加简单明了，无论是对 URL 的处理还是对 Payload 的编码，REST 都倾向于用更加简单轻量的方法设计和实现。值得注意的是 REST 并没有一个明确的标准，而更像是一种设计的风格。