单点登录学习笔记

#爱屋及乌

已于 2022-10-27 22:30:04 修改

阅读量452

点赞数 1

文章标签：服务器 servlet java

于 2022-10-08 16:32:36 首次发布

本文链接：https://blog.csdn.net/Suphans/article/details/127195175

版权

3.3.1 Spring Security 的特点

3.4 关于Token与JWT

3.4.1 Session与Token对比

3.4.2 JWT说明

3.4.3JWT的认证流程：

1 单点登录概述

单点登录的英文名叫做：Single Sign On（简称SSO），指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的系统。简而言之，一次登录,即可访问该平台下的所有应用。

2 单点登录流程

SSO需要一个独立的认证中心，所有子系统都通过认证中心的登录入口进行登录，登录时带上自己的地址，子系统只接受认证中心的授权，授权通过令牌（token）实现，SSO认证中心负责验证用户的用户名密码正确与否，若正确则创建全局会话和token，token中包含的就是用户的部分登录信息.

第一次访问的时候:无论是什么模块,由于没有对应的token信息,首先经过SSO验证中心,生成token信息,登录信息正确则生成对用的token信息,通过发送给客户端. 之后用户在该网站的所有访问请求都会携带token信息(token信息可以通过地址栏或者cookie携带).

第二次(n次)访问的时候:浏览器会自动的从本地cookie记录中找到匹配访问当前网站域名的cookie,并作为请求头发送,服务端会解析其中的token信息,验证通过则允许访问,否则需要重新登录验证.

3 单点登录实现涉及的知识点

3.1 Cookie的属性

Cookie是一段不超过4KB的小型文本数据，数据存储类型与Map类似,由一个名称Name和一个Value 以及其它几个用于控制Cookie有效期、安全性、使用范围的可选属性组成，以下是部分属性说明。

1.Name
Name是Cookie的名称，Cookie一旦创建，名称便不可更改，一般不区分大小写。

2.Value
Value是cookie名称Name对应的Cookie的值，如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码。

3.Domain
指定Cookie的有效域，决定在向该域发送请求时是否携带此Cookie.对于某个网站来讲,设置的值是该网站的顶级域名

4 Path属性：定义了Web站点上可以访问该Cookie的目录

5.Expires/Max-age
Expires和Max-age均为Cookie的有效期设置属性，Expires是该Cookie被删除时的时间戳，格式为GMT,若设置为以前的时间，则该Cookie立刻被删除，并且该时间戳是服务器时间，不是本地时间！若不设置则默认页面关闭时删除该Cookie。max-age也是Cookie的有效期，但它的单位为秒，即多少秒之后失效，若Max-age设置为0，则立刻失效，设置为负数，则在页面关闭时失效。Max-age默认为 -1。如果max-age为0，则表示删除该cookie。cookie机制没有提供删除cookie的方法，因此通过设置该cookie即时失效实现删除。

6.HttpOnly
用于避免cookie被Javascript访问，值为 true 或 false，默认false。若设置为true，则不允许通过脚本document.cookie去更改这个值，同样这个值在document.cookie中也不可见，但在发送请求时依旧会携带此Cookie。

7.Secure
Cookie的安全属性，用于指定cookie需要通过安全Socket层连接传递。值为 true 或 false，默认值false，若设置为true，则浏览器只会在HTTPS和SSL等安全协议中传输此Cookie，不会在不安全的HTTP协议中传输此Cookie。

3.2 跨域问题

跨域访问，是在一个域名的网页中去请求另一个域名的资源。比如从 taobao.com页面去请求 baidu.com 的资源。一般情况下浏览器禁止跨域访问，因为有 “ 同源策略 ” 存在，这是浏览器基于用户信息安全,对 JavaScript 施加的安全限制。
同源策略 :A 网站页面访问 B 网站的资源受限（跨域访问），除非 A 和 B 是 “ 同源 ” 。
“ 同源 ” 是指三个相同：

协议相同(反例,例如ftp,https)
域名相同(反例,例如http://www.taobao.com和http://www.baidu.com)
端口相同(反例,例如http://localhost:8080和http://localhost:8081)

这三个里面只要有任何一个地方不同，就认为是跨域。如果非同源（跨域）会受到拦截,

3.3 Spring Security

项目并不是大型微服务项目,所以验证中心采用的并不是CAS, 而是使用Spring Sercurity作为认证中心并进行相关配置.

springsecurity底层实现为一条过滤器链，主要功能是两方面

认证：验证用户提交的登录信息，判断是否可以通过。

授权：当认证通过后，给予通过认证的用户一些信息，后续，将根据这些信息来判断此用户是否允许执行某些访问。

需要导入以下依赖:

<!-- Spring Boot Security，用于处理认证与授权 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

3.3.1 Spring Security 的特点

当添加以上依赖项后，再次启动项目，Spring Security会执行自动配置，使

此主机上所有的请求都必须先登录才可以访问，并提供了登录页面，包括根本不存在的URL

此特点是由WebSecurityConfigurerAdapter类中的protected void configure(HttpSecurity http)方法决定的. 此配置方法中的http.formLogin()将决定是否开启登录表单

默认的用户名是user，默认是密码在启动日志中，每次启动都会变化 ,并且会显示到terminal中,例如

Using generated security password: 47662850-fc2d-b3a6-ee10-2404ac26r442d

当登录成功后，会自动跳转到此前尝试访问的URL. 例如，当尝试访问 http://localhost:9080/ 时，由于没有登录，会自动重定向到 http://localhost:9080/login 显示了登录页面，当登录成功后，会自动重定向到此前尝试访问的 http://localhost:9080/
Spring Security默认使用Session保存用户的登录信息例如，当关闭浏览器后，再次访问，需要重新登录通过 http://localhost:9080/logout 退出登录
自带BCryptPasswordEncoder，可以用于使用BCrypt算法对密码进行加密处理
如果项目运行时Spring容器中有密码编码器（PasswordEncoder），Spring Security框架会自动使用它
Spring Security默认开启了“禁止跨域的异步提交”，避免“伪造的跨域攻击”
在HTTP协议中，401表示未认证的，通常是没有成功登录的，403表示未授权的，通常是已经登录，但是不具备相关的操作权限。在Spring Security中，在许多“禁止”的场景中都会使用403，并不完全符全HTTP协议的规范.
Spring Security在防止伪造跨域攻击时，会自动生成值为UUID的Token（票据 / 令牌），并且，将此值响应给客户端，针对客户端后续提交的 POST / DELETE / PUT / PATCH 类型的请求，都要求携带名为 _csrf 的参数，且值就是此UUID，如果客户端提交请求时没有携带此值，则视为“伪造的跨域攻击”，将响应 403 错误。

在继承了WebSecurityConfigurerAdapter的配置类中，重写configurer(HttpSecurity http)方法，调用http.csrf().disable()即可禁用它，即不再检查各请求是否为“伪造跨域”的访问。禁用后，会存在被伪造跨域攻击的风险
Spring Security默认使用Session保存认证信息

3.4 关于Token与JWT

对于Token,其意思是票据，令牌。当用户尝试登录，将请求提交到服务器端，如果服务器端认证通过，会生成一个Token数据并响应到客户端，此Token是有意义的数据,包含了用于用户验证的信息，此客户端在后续的每一次请求中，都应该携带此Token数据，而服务器端通过解析此Token来识别用户身份！

3.4.1 Session与Token对比

Session默认是保存在服务器的内存中的数据，会占用一定的服务器内存资源，并且，不适合集群或分布式系统（虽然可以通过共享Session来解决），客户携带的Session ID只具有唯一性的特点（理论上），不具备数据含义……而Token的本质是将有意义的数据进行加密处理后的结果，各服务器都只需要具有解析这个加密数据的功能即可获取到其中的信息含义，理论上不占用内存资源，更适用于集群和分布式系统，但是，存在一定的被解密的风险（概率极低）。

3.4.2 JWT说明

JWT = JSON Web Token，是使用JSON格式表示多项数据的Token。

在使用JWT时，需要在项目中添加相关的依赖，用于生成JWT和解析JWT，例如：

<!-- JJWT（Java JWT） -->
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>

JWT的本质就是一个字符串，它是将用户信息保存到一个Json字符串中，并进行加密和签名,最终得到的字符串作为一个token,可以用于在各方之间安全地将信息传输。

一个原始的JWT数据应该包含3个部分：

HEADER：ALGORITHM & TOKEN TYPE（算法与Token类型）,alg表示使用的加密算法,typ表示数据类型

{
  "alg": "HS256",
  "typ": "JWT"
}

PAYLOAD（载荷）：DATA

此部分的数据是自定义的，可以根据需要存入对应的数据, 形式与map类似,是以 "键:值" 的形式进行存入。

{ 
  "name": "JiWu",
  "phone": 1234567890,
}

VERIFY SIGNATURE（验证签名）

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
)

3.4.3JWT的认证流程：

JWT的认证流程大致如下:

1，前端接受到服务请求,检查token,没有token或token不合法(如过期,签名错误等),跳转到SSO,重新验证登录用户信息,若验证成功, 则将用户信息中的用户名,密码,权限,启用等信息封装进入JWT的PAYLOAD中,并与签名一起,按照HEADER中设置的alg加密算法进行加密.最终生成一个jwt的字符串.

2 对于(后端)生成的JWT,将会被返回给前端(前端可以根据需求将它存储到localstorage中,用户退出登录时删除) ,前端将JWT返回给客户端,要求客户端的每次请求都必须包含JWT信息,(JWT信息可以作为请求头中的Authorization的值，也可以是存储在cookie中发送给客户，cookie的域名设置为访问网站的顶级域名，之后客户用浏览器访问该网站会自动携带cookie)

3 客户端的每一次请求都会携带jwt,后端会对每一次从前端发回来的请求进行认证和权限检验.检验通过则执行相关业务,否则进行拦截.