单点登录(SSO)详解

刺骨的言语ヽ痛彻心扉 2024-03-24 13:57 65阅读 0赞

#### 文章目录 ####

前言

一、单点登录是什么？

二、单点登录的实现方式

1.Cookie方案：

2.Session方案：

3.Token方案：

三、JWT是什么

1.JWT的概况

2.JWT的组成

3.JWT的用法

4.JWT优缺点

四、Token实现单点登录（代码）

1.添加JWT依赖与JWT工具类

2.编写登录方法

总结

--------------------

## 前言 ##

在分布式项目架构中，为了提高用户体验性，用户只需要认证一次便可以在多个拥有访问权限的系统中访问，这个功能叫做单点登录（SSO）。现在市面上大多采用OAuth2.0实现单点登录，次方案下需要另准备一个统一认证中心系统。此文章只是SSO简单实现，所以没用OAuth2.0。想了解OAuth2.0相关内容，请看下一篇文章。

--------------------

## 一、单点登录是什么？ ##

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有**相互信任**的应用系统（例如淘宝、天猫之间的关系）。**简而言之，多个系统，统一登陆。**

单点登录主要强调的是**登录以后，**各个系统间数据共享问题。

--------------------

## 二、单点登录的实现方式 ##

单点登录的实现方案，一般就包含：Cookie、Session、Token

### 1.Cookie方案： ###

**流程：**

用cookie作为媒介存放用户凭证。 用户登录系统之后，会返回一个加密的cookie，当用户访问子应用的时候会带上这个cookie，授权以解密cookie并进行校验，校验通过后即可登录当前用户。

![d5413522bdde4554a7e50db70e6e5883.png][]

**缺点：**

（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.S**ession方案：** ###

**流程：**

因为是分布式的系统，**多服务器是不共享session**，传统的单机session不适用于分布式系统中，所以这里使用分布式session。session属于有状态，实现分布式session有四种方案（session复制、客户端存储、HASH一致性、统一存储）。详情请看：[分布式session解决方案\_半格咖啡的博客-CSDN博客][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方案： ###

流程：

![8f437f1c9a984adabdbf50ae4d19630c.png][]

> 现如今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][]

**组成：**

![7201e08c308946bcad95929cde2689ea.png][]

#### `` ####

###  ###

![f0407fec07904b11abc2fdc7a651e1eb.png][]

该对象为一个很长的字符串，字符之间通过`"."`分隔符分为三个子串。

每一个子串表示了一个功能块，总共有以下三个部分：**`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工具类 ###

依赖：

<dependency>
                <groupId>io.jsonwebtoken</groupId>
                <artifactId>jjwt</artifactId>
                <version>0.9.1</version>
            </dependency>

工具类：

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;
        }
    
        /**
         * 判断token是否存在与有效
         *
         * @param jwtToken
         * @return
         */
        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;
        }
    
        /**
         * 判断token是否存在与有效
         *
         * @param request
         * @return
         */
        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;
        }
    
        /**
         * 根据token获取id
         *
         * @param request
         * @return
         */
        public static String getMemberIdByJwtToken(HttpServletRequest request) {
            String jwtToken = request.getHeader("token");
            if (StringUtils.isEmpty(jwtToken)) return "";
            //根据设置的防伪码解析token，获取对象
            Jws<Claims> 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的做法我会在之后的文章写出。因为大多是自己理解，可能有不少错误的地方。欢迎大家在评论区指正。

[d5413522bdde4554a7e50db70e6e5883.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a4dacfe56d40485c833d983fd731201a.png
[session_-CSDN]: https://blog.csdn.net/hxxzbgkf/article/details/122727176
[8f437f1c9a984adabdbf50ae4d19630c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/68a9e3d3467e4e3db8e2f5710f01e199.png
[JSON Web Tokens - jwt.io]: https://jwt.io/
[7201e08c308946bcad95929cde2689ea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/630498fe68a347979b626f12f0945c9e.png
[f0407fec07904b11abc2fdc7a651e1eb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b475ba57d3cb4df8b16dcbbac119a6fb.png