单点登录解决方案

1、HTTP Session

1.1、HTTP无状态性

HTTP协议本身是无状态的， 客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没必要记录彼此过去的行为，每一次请求之间是独立的然后我们很快发现如果能够提供一些按照需要生成的动态信息会使 web 变得更加有用。 比如我们做了一个需要登录授权才能执行的动作，但是因为 http 协议没办法保存这个登录的用户的状态，因此当下一次再执行一个需要授权操作时，还需要再次登录。 这将导致用户体验非常差。因此需要一种机制能够识别每次请求的用户， 来实现会话保存的目的。

1.2、Session

服务端提供了一种叫 Session 的机制，对于每个用户的请求，会生成一个唯一的标识。 当程序需要为某个客户端的请求创建一个 session 的时候，服务器首先检查这个客户端的请求是否包含了一个 session 标识- session id；如果已包含一个 session id 则说明以前已经为客户端创建过 session，服务器就按照 session id 把这个 session 检索出来使用（如果检索不到，会新建一个）；如果客户端请求不包含 sessionid，则为此客户端创建一个session 并且生成一个与此 session 相关联的 session id，session id 的值是一个既不会重复，又不容易被找到规律的仿造字符串。 [客户端是如何存储 sessionid 的呢？ ]

1.3、Cookie

浏览器提供了一种叫 cookie 的机制，保存当前会话的唯一标识。每次 HTTP 请求，客户端都会发送相应的 Cookie 信息到服务端。 客户端第一次请求，由于 cookie 中并没有携带 sessionid，服务端会创建一个 sessionid，写入到客户端的 cookie 中。以后每次请求，都会携带这个 id 给到服务器端。这样一来，便解决了无状态的问题。 [如果客户端浏览器禁用了 cookie，一般会通过 URL 重写的方式来进行会话会话嗯个总，也就是在 url 中携带 sessionid。

2、集群环境下的 session 共享问题

如果网站请求流量较大，那么单台Web服务器是无法承接这些流量的，这个时候就需要开始对服务器做集群。采用了多台机器做集群以后， 就势必要通过一种机制来实现请求的路由。因为对于用户来说，我访问的是一个域名，至于后端应该请求到哪一台，用户并不需要关心。 所以这里会使用负载均衡设备；

2.1、关于负载均衡

负载均衡的主要目的是： 把用户的请求分发到多台后端的设备上，用以均衡服务器的负载。我们可以把负载均衡器划分为两大类：硬件负载均衡器和软件负载均衡器。
硬件负载
最常用的硬件负载设备有 F5 和 netscaler、 Redware， F5是基于 4 层负载， netscaler 是 7 层负载。
硬件负载均衡设备的优点是稳定性高、 同时有专门的技术服务团队支撑。 但是价格比较贵， 一般的都要几十万起。所以那种大的企业，没有专业的运维团队。 直接花钱买解决方案。
软件负载
比较主流的开源软件负载技术有: lvs、 HAProxy、 Nginx 等，对于小公司来说或者大型的互联网企业，基本都采用软件负载均衡技术来实现流量均衡。
不同的负载均衡技术有不同的特点，比如 LVS 是基于 4 层的负载负载技术，抗负载能力比较强HAProxy 和 Nginx 是基于 7 层的负载均衡技术，需要根据请求的 url 进行分流。

2.2、负载均衡算法

引入负载均衡器以后，就势必需要一个负载均衡算法对请求进行转发，那么，常见的负载均衡算法有以下几种：

轮询算法及加权轮询算
轮询法是指负载均衡服务器将客户端请求按顺序轮流分配到后端服务器上，以达到负载均衡的目的。
假设现在有 6 个客户端请求， 2 台后端服务器。当第一个请求到达负载均衡服务器时，负载均衡服务器会将这个请求分派到后端服务器 1；当第二个请求到害时，负载均衡服务器会将这个请求分派到后端服务器 2。然后第三个请求到达，由于只有两台后端服务器，故请求 3 会被分派到后端服务器 1。
对于后端服务器的性能差异， 可以对处理能力较好的服务器增加权重，这样，性能好的服务器能处理更多的任务，性能较差的服务器处理较少的任务。
假设有 6 个客户端请求， 2 台后端服务器。后端服务器 1 被赋予权值 5，后端服务器 2 被赋予赋予权值 1。这样一来，客户端请求 1， 2， 3， 4， 5 都被分派到服务器 1 处理；客户端请求 6 被分派到服务器 2 处理。接下来，请求 7， 8，9， 10， 11 被分派到服务器 1，请求 12 被分派到服务器 2。

最小连接数
由于不同的客户端请求的操作对于后端来说复杂度是不同的，也就会导致服务端的处理时间也不一样。最小连接数法根据后端服务器当前的连接数情况，动态地选取其中积压连接数最小的一台服务器来处理当前的请求，尽可能提高后端服务器的利用效率，合理地将请求分流到每一台服务器。

随机算法
随机法也很简单，就是随机选择一台后端服务器进行请求的处理。由于每次服务器被挑中的概率都一样，客户端的请求可以被均匀地分派到所有的后端服务器上。

哈希算法
根据获取客户端的 IP 地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一 IP 地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

3、Session 共享问题的解决方法

Session 共享问题，其实已经有非常多的解决方案，那么接下来我们一一分析。

3.1、session sticky

session sticky(粘性) , 保证同一个会话的请求都在同一个web 服务器上处理，这样的话，就完全不需要考虑到会话的问题了。 比如前面说的负载均衡算法中，哈希算法就是一个典型的实现手段。
这种实现方式会有些问题：

1. 如果一台 web 服务器宕机或者重启，那么这台机器上保存的会话数据都会丢失，会造成用户暂时无法访问的问题，或者用户之前的授权操作需要再执行一次
2. 通过这种方式实现的 session 保持，没有办法进行 4 层网络转发，只能在 7 层网络上进行解析并转发

3.2、session replication

session 复制， 通过相关技术实现 session 复制， 使得集群中的各个服务器相互保存各自节点存储的 session 数据。
tomcat 本身就可以实现 session 复制的功能，基于 IP 组播放方式。
这种实现方式的问题：

1. 同步 session 数据会造成网络开销，随着集群规模越大，同步 session 带来的带宽影响也越大
2. 每个节点需要保存集群中所有节点的 session 数据，就需要比较大的内存来存储。

3.3、session 统一存储

集群中的各个节点的 session 数据，统一存储到一个存储设备中。那么每个节点去拿 session 的时候，就不是从自己的内存中去获得，而是从相应的第三方存储中去拿。对于这个方案来说，无论是哪个节点新增或者修改了 session 数据，最终都会发生在这个集中存储的地方。这个存储设备可以是 redis、也可以是 mysql。
这种实现方式的问题：

1. 读写 session 数据需要进行网络操作，存在不稳定性和延迟性
2. 如果存储 session 的服务器出现故障， 将大规模的影响到应用

3.4、Cookie Based

Cookie Based 方法， 简单来说，就是不依赖容器本身的Session 机制。而是服务端基于一定的算法，生成一个 token 给到客户端，客户端每次请求，都会携带这个 token。当服务端收到 token 以后， 先验证 token 是否有效，再解密这个 token 获取关键数据进行处理。

4、session 统一存储实践

4.1、引入依赖

<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
    <version>${spring-session-data-redis.version}</version>
</dependency>

4.2、添加注解@EnableSpringHttpSession

将此批注添加到@Configuration类，以将SessionRepositoryFilter公开为名为“springSessionRepositoryFilter”的bean。要使用它，您必须提供SessionRepository。如

@Configuration
@EnableSpringHttpSession
public class SpringHttpSessionConfig {
    @Bean
    public MapSessionRepository sessionRepository() {
        return new MapSessionRepository();
    }
}

具体原理请看《使用spring-session-data-redis实现HTTP Session集中管理原理》

5、Cookie Based 实现方式

基于纯 Cookie 的方式，也就是客户端每次请求都携带身份信息给到服务端。 比较典型的方式是 JWT，全称是 JSON Web Tokens。 是一种简洁的并且在两个计算机之间安全传递信息的表述性声明规范。 JWT 的声明一般被用来在客户端和服务端之间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。

关于JWT请参考《认识JWT》

5.1、基于 JWT 的交互过程

很多同学会发现这个和最原始的 cookie+session 方式是一样的，其实不是， JWT 强调的是服务端不对 token进行存储，而是直接通过签名算法验证并解密 token 得到相应数据进行处理。

5.2、JWT的组成

JWT由三个部分组成，头部（header）、有效载荷（playload）、签名（signature），打开网站： https://jwt.io/。
header
格 式 如 下 ， typ 和 alg 分 别 对 应 的 全 称 是 type( 类 型 ) 和algorithm(算法)， 类型可以自定义。 alg:hs256 表示当前 token
是使用 HS256 算法来进行加密的。
playload
Payload 里面是 Token 的具体内容，也是一个 json 字符串，这些内容里面有一些是标准字段，你也可以添加其它需要的内容； payload 的 json 结构并不像 header 那么简单， payload 用来承载要传递的数据，它的 json 结构实际上是对 JWT 要传递的数据的一组声明，这些声明被 JWT标准称为 claims , JWT 默认提供了一些标准的 Claim， 具体内容如下。
每一个 claim 都有特定的含义和作用。

➢ iss(Issuser)：代表这个 JWT 的签发主体；
➢ sub(Subject)：代表这个 JWT 的主体，即它的所有人；
➢ aud(Audience)：代表这个 JWT 的接收对象；
➢ exp(Expiration time)：是一个时间戳，代表这个 JWT 的过期时间；
➢ nbf(Not Before)：是一个时间戳，代表这个 JWT 生效的开始时间，意味着在这个时间之前验证 JWT 是会失败的；
➢ iat(Issued at)：是一个时间戳，代表这个 JWT 的签发时间；
➢ jti(JWT ID)：是 JWT 的唯一标识。

按照 JWT 标准的说明： 标准的 claims 都是可选的，在生成playload 不强制用上面的那些 claim，你可以完全按照自己的想法来定义 payload 的结构，不过这样搞根本没必要：
第一是，如果把 JWT 用于认证， 那么 JWT 标准内规定的几个 claim就足够用了，甚至只需要其中一两个就可以了，假如想往 JWT 里多存一些用户业务信息，比如角色和用户名等，这倒是用自定义的 claim 来添加；
第二是， JWT 标准里面针对它自己规定的 claim 都提供了有详细的验证规则描述，每个实现库都会参照这个描述来提供 JWT 的验证实现，所以如果是自定义的 claim 名称，那么你用到的实现库就不会主动去验证这些 claim。
signature
创建签名需要使用编码后的 header 和 payload 以及一个密钥，使用 header 中指定签名算法进行签名。 组成格式如下 、

➢header (base64 后的)
➢ payload (base64 后的)
➢ secret
这个部分需要 base64 加密后的 header 和 base64 加密后的 payload 使用.连接组成的字符串，然后通过 header 中声明的加密方式进行加盐 secret 组合加密，然后就构成了jwt 的第三部分。
signature=HS256(base64(header)+”.”+base64(payload),secret);
最后将这 3 个部分组成一个完整的字符串构成了 JWT：
base64(header)+”.”+base64(payload)+”.”+sinature
secret 是保存在服务器端的， jwt 的签发生成也是在服务器端的，secret 就是用来进行 jwt 的签发和 jwt 的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个 secret, 那就意味着客户端是可以自我签发 jwt 了。

5.3、总结

其实大家会发现， jwt 实际上就是定义了一套数据加密以及验签的算法的规范，根据这个规范来实现单点登录，以及数据传输及验签功能。 但是这个方案会存在一些问题比如： 不能传递敏感信息， 因为 jwt 中的部分内容可以解密，只是不能修改而已。

5.4、代码实现

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

创建TokenUtils类

package xxxxxx;

import java.security.Key;
import java.util.Date;
import java.util.Map;

import javax.crypto.spec.SecretKeySpec;

import org.apache.commons.codec.binary.Base64;

import xxxxxx.Cst;

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jws;
import io.jsonwebtoken.JwtBuilder;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.impl.crypto.MacProvider;

public class TokenUtils {
    // 版本
    public static String TOKEN_VERSION = "1";
    // 设置发行人
    public static String ISSUER = "zhicall";
    // 设置抽象主题
    public static String SUBJECT = "subject";
    
    // HS256 私钥
    public static String HS256KEY = "xxxxxx";
    
    public static SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
    
    public static Key signingKey = new SecretKeySpec(Base64.decodeBase64(HS256KEY), signatureAlgorithm.getJcaName());

    public static String getJWTString(String login, Map<String, Object> claims) {
        
        long nowMillis = System.currentTimeMillis();
        claims.put(Claims.ID, TOKEN_VERSION);
        claims.put(Claims.ISSUER, ISSUER);
        claims.put(Claims.SUBJECT, SUBJECT);
        claims.put(Claims.AUDIENCE, login);
        claims.put(Claims.EXPIRATION, new Date(nowMillis + (Cst.TOKEN_TIMEOUT_MIN * 60 * 1000)));
        claims.put(Claims.ISSUED_AT, new Date(nowMillis));
        
        JwtBuilder jwtBuilder = Jwts.builder().setClaims(claims);
        //System.out.println(System.currentTimeMillis() - nowMillis);
        jwtBuilder.signWith(signatureAlgorithm, signingKey);
        return jwtBuilder.compact();
    }

    public static boolean isValid(String token) {
        try {
            Jws<Claims> jwsClaims = Jwts.parser().setSigningKey(signingKey).parseClaimsJws(token.trim());
            Long exp = (Long) jwsClaims.getBody().get(Claims.EXPIRATION);
            //System.out.println(exp - System.currentTimeMillis());
            return exp - System.currentTimeMillis() > 0;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }

    public static Map<String, Object> parseJWTtoMap(String token) {
        Claims claims = Jwts.parser().setSigningKey(signingKey).parseClaimsJws(token.trim()).getBody();
        return claims;
    }
    
    public static String getHS512Key() {
        Key key = MacProvider.generateKey(SignatureAlgorithm.HS512);
        String keyStr = Base64.encodeBase64String(key.getEncoded());
        return keyStr;
    }
}

在Web层创建一个拦截器TokenIntercepter用于拦截HTTP请求。

public class TokenIntercepter extends HandlerInterceptorAdapter {
    private final String ACCESS_TOKEN="access_token";

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {
        if(!(handler instanceof HandlerMethod)){
            return true;
        }
        HandlerMethod handlerMethod=(HandlerMethod)handler;
        Object bean=handlerMethod.getBean();
        String token=CookieUtil.getCookieValue(request,ACCESS_TOKEN);
        boolean isAjax=CookieUtil.isAjax(request);
        if(StringUtils.isEmpty(token)){
            if(isAjax){
                response.setContentType("text/html;charset=UTF-8");
                response.getWriter().write("{\"code\":\"-1\",\"msg\":\"error\"}");
                return false;
            }
            response.sendRedirect(GpmallWebConstant.GPMALL_SSO_ACCESS_URL);
            return false;
        }
        if(TokenUtils.isValid(token)){
            //可将token body保存到当前线程
            TokenUtils.parseJWTtoMap(token);
            return super.preHandle(request, response, handler);
        }
        if(isAjax){
            response.setContentType("text/html;charset=UTF-8");
            response.getWriter().write("{\"code\":\""+checkAuthResponse.getCode()+"\"" +
                    ",\"msg\":\""+checkAuthResponse.getMsg()+"\"}");
            return false;
        }
        response.sendRedirect(GpmallWebConstant.GPMALL_SSO_ACCESS_URL);
        return false;
    }
}