文章目录
前言
在分布式项目架构中，为了提高用户体验性，用户只需要认证一次便可以在多个拥有访问权限的系统中访问，这个功能叫做单点登录（SSO）。现在市面上大多采用OAuth2.0实现单点登录，次方案下需要另准备一个统一认证中心系统。此文章只是SSO简单实现，所以没用OAuth2.0。想了解OAuth2.0相关内容，请看下一篇文章。
一、单点登录是什么？
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统（例如淘宝、天猫之间的关系）。简而言之，多个系统，统一登陆。
单点登录主要强调的是登录以后，各个系统间数据共享问题。
二、单点登录的实现方式
单点登录的实现方案，一般就包含：Cookie、Session、Token
1.Cookie方案：
流程：
用cookie作为媒介存放用户凭证。 用户登录系统之后，会返回一个加密的cookie，当用户访问子应用的时候会带上这个cookie，授权以解密cookie并进行校验，校验通过后即可登录当前用户。
缺点：
（1）Cookie不安全：攻击者可以通过伪造Cookie伪造成特定用户身份，可以用加密规避（前提是加密算法不被泄露）。
（2）不能跨域实现免登：Cookie一般是以域名为分割的。如：baidu.com 无法读到 cnblogs.com 写的 cookie。域名是可以访问上级域名的Cookie的。 即a.baidu.com是可以访问baidu.com下的Cookie的。（一级域名相同，只是二级或更高级域名不同的站点，如：a.baidu.com、b.baidu.com可以通过设置 domain 参数共享 cookie 读写。）
补充：域名通过 “.” 号切分后，从右往左看，不包含 “.” 的是顶级域名，包含一个 “.”的是一级域名，如：baidu.com， 包含两个“.”的是二级域名，如：a. baidu.com ，以此类推。
2.Session方案：
流程：
因为是分布式的系统，多服务器是不共享session，传统的单机session不适用于分布式系统中，所以这里使用分布式session。session属于有状态，实现分布式session有四种方案（session复制、客户端存储、HASH一致性、统一存储）。详情请看：分布式session解决方案_半格咖啡的博客-CSDN博客
流程运行：
（1） 用户第一次登录时，将会话信息（用户Id和用户信息），比如以用户Id为Key，写入分布式Session；
（2） 用户再次登录时，获取分布式Session，是否有会话信息，如果没有则调到登录页；
（3） 一般采用Cache中间件实现，建议使用Redis，因此它有持久化功能，方便分布式Session宕机后，可以从持久化存储中加载会话信息；
（4） 存入会话时，可以设置会话保持的时间，比如15分钟，超过后自动超时；
缺点：
（1）服务器压力增大：通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。（可以将数据保存在磁盘中）
（2）扩展性不强：如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。（可以使用分布式session将session在各个集群中保持一致）
（3）CSRF跨站伪造请求攻击：session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
3.Token方案：
流程：
现如今Token方案登录认证大多采用OAuth2.0方案，这里只是简单实现sso效果，所以没实现OAuth2.0流程。
缺点：
（1）占用带宽
（2）无法在服务器端销毁（token生成后就返回给了客户端，服务器端无法进行删除）
注：基于微服务开发，选择token的形式相对较多，因此我之后会使用token实现sso
三、JWT是什么
1.JWT的概况
通俗讲：就是一种生存字符串的规则叫JWT。JWT是JSON WEB TOKEN的缩写，它是基于 RFC 7519 标准定义的一种可以安全传输的的JSON对象，由于使用了数字签名，所以是可信任和安全的。
Token（令牌）属于无状态，因每个人制定的规则不同，生成的结果也不同。目前，多数人采用JWT为统一令牌标准，之后我也采用JWT作为token生成标准。
2.JWT的组成
jwt实例可以在该网站上获得解析结果：JSON Web Tokens - jwt.io
组成：
该对象为一个很长的字符串，字符之间通过"."分隔符分为三个子串。
每一个子串表示了一个功能块，总共有以下三个部分：JWT头、有效载荷和签名
JWT头:
JWT头部分是一个描述JWT元数据的JSON对象，通常如下所示。
{ "alg": "HS256", "typ": "JWT"}在上面的代码中，
alg属性表示签名使用的算法，默认为HMAC SHA256（写为HS256）；
typ属性表示令牌的类型，JWT令牌统一写为JWT。
最后，使用Base64 URL算法将上述JSON对象转换为字符串保存。
有效载荷【用户信息】:
(通俗的讲就是用户信息)有效载荷部分，是JWT的主体内容部分，也是一个JSON对象，包含需要传递的数据。 JWT指定七个默认字段供选择
iss：发行人exp：到期时间sub：主题aud：用户nbf：在此之前不可用iat：发布时间jti：JWT ID用于标识该JWT除以上默认字段外，我们还可以自定义私有字段，如下例：
{ "sub": "1234567890", "name": "Helen", "admin": true}请注意，默认情况下JWT是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防止信息泄露。
JSON对象也使用Base64 URL算法转换为字符串保存。
签名哈希【防伪标志】:
签名哈希部分是对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。
首先，需要指定一个密码（secret）。该密码仅仅为保存在服务器中，并且不能向用户公开。然后，使用标头中指定的签名算法（默认情况下为HMAC SHA256）根据以下公式生成签名。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)在计算出签名哈希后，JWT头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用"."分隔，就构成整个JWT对象。
Base64URL算法：
如前所述，JWT头和有效载荷序列化的算法都用到了Base64URL。该算法和常见Base64算法类似，稍有差别。 作为令牌的JWT可以放在URL中（例如api.example/?token=xxx）。 Base64中用的三个字符是"+"，"/“和”="，由于在URL中有特殊含义，因此Base64URL中对他们做了替换："=“去掉，”+“用”-“替换，”/“用”_"替换，这就是Base64URL算法。
3.JWT的用法
客户端接收服务器返回的JWT，将其存储在Cookie或localStorage中。
此后，客户端将在与服务器交互中都会带JWT。如果将它存储在Cookie中，就可以自动发送，但是不会跨域，因此一般是将它放入HTTP请求的Header Authorization字段中。当跨域时，也可以将JWT被放置于POST请求的数据主体中。
4.JWT优缺点
- JWT不仅可用于认证，还可用于信息交换。善用JWT有助于减少服务器请求数据库的次数。
- 生产的token可以包含基本信息，比如id、用户昵称、头像等信息，避免再次查库
- 存储在客户端，不占用服务端的内存资源
- JWT默认不加密，但可以加密。生成原始令牌后，可以再次对其进行加密。
- 当JWT未加密时，一些私密数据无法通过JWT传输。
- JWT的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦JWT签发，在有效期内将会一直有效。
- JWT本身包含认证信息，token是经过base64编码，所以可以解码，因此token加密前的对象不应该包含敏感信息，一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。
- 为了减少盗用和窃取，JWT不建议使用HTTP协议来传输代码，而是使用加密的HTTPS协议进行传输。
四、Token实现单点登录（代码）
1.添加JWT依赖与JWT工具类
依赖：
io.jsonwebtoken jjwt 0.9.1 工具类：
public class JwtUtils { //token过期时间 public static final long EXPIRE = 1000 * 60 * 60 * 24; //秘钥，每个公司生成规则不一样 public static final String APP_SECRET = "rikka六花"; //生成token字符串方法,参数根据自己实际要求指定 public static String getJwtToken(String id, String nickname) { String JwtToken = Jwts.builder() //设置jwt头信息，红色部分，内容固定，不需要改 .setHeaderParam("typ", "JWT") .setHeaderParam("alg", "HS256") .setSubject("guli-user")//设置主题（可选） .setIssuedAt(new Date())//设置发布时间（可选） .setExpiration(new Date(System.currentTimeMillis() + EXPIRE))//设置过期时间 //设置token主体部分，存储用户信息，可设置多个值 .claim("id", id) .claim("nickname", nickname) //设置签名哈希（防伪标志） .signWith(SignatureAlgorithm.HS256, APP_SECRET) .compact(); return JwtToken; } public static boolean checkToken(String jwtToken) { if (StringUtils.isEmpty(jwtToken)) return false; try { //根据设置的防伪码解析token Jwts.parser().setSigningKey(APP_SECRET).parseClaimsJws(jwtToken); } catch (Exception e) { e.printStackTrace(); return false; } return true; } public static boolean checkToken(HttpServletRequest request) { try { String jwtToken = request.getHeader("token"); if (StringUtils.isEmpty(jwtToken)) return false; //根据设置的防伪码解析token Jwts.parser().setSigningKey(APP_SECRET).parseClaimsJws(jwtToken); } catch (Exception e) { e.printStackTrace(); return false; } return true; } public static String getMemberIdByJwtToken(HttpServletRequest request) { String jwtToken = request.getHeader("token"); if (StringUtils.isEmpty(jwtToken)) return ""; //根据设置的防伪码解析token，获取对象 Jws claimsJws = Jwts.parser().setSigningKey(APP_SECRET).parseClaimsJws(jwtToken); //获取token有效载荷【用户信息】 Claims claims = claimsJws.getBody(); return (String) claims.get("id"); }} 2.编写登录方法
@Override public String login(LoginVo loginVo) { //写你自己的具体登录逻辑： //1.判断参数是否为空 ... //2.判断数据库是否存在该用户 ... //3.判断加密后的密码参数和数据库是否一致 ... //4.判断用户是否禁用 ... //5.生成jwt令牌返回给前端 return JwtUtils.getJwtToken(ucenterMember.getId(), ucenterMember.getNickname()); }将JWT返回给前端，前端选择将令牌存入cookie或放进地址栏。之后每次都带着JWT发送请求，因为JWT有效载荷里存有id，所以下次后端可根据id查找对应用户信息返回。可根据是否有token判断是否登录，所以单点登录就实现了。
总结
单点登录在我看来是强调登录之后，下次请求是否有token，并根据token实现数据共享的问题。完整流程应该是：结合security和oauth2.0，先由security拦截请求解析token。如果token合法，便继续代码流程；若违法，便跳转到登录页面进行登录，登录请求发送到统一授权中心进行校验然后颁发令牌，根据令牌实现了单点登录或请求详细信息。
以上就是个人对单点登录的理解，关于结合security和oauth2.0的做法我会在之后的文章写出。因为大多是自己理解，可能有不少错误的地方。欢迎大家在评论区指正。
来源地址：https://blog.csdn.net/weixin_58403235/article/details/129928096
