Session共享

Session共享问题有以下几种方案：

• Session复制，session发生变化，集群中的服务器将会进行同步

  • 牵一发而动前身，某个session发生变化，所有服务器都要进行同步

  • 集群机器数量大或者用户数量大时，同步的网络开销也就越大

  • 每台服务器都含有session，造成数据冗余，资源浪费

• Session集中存储

  • 实现简单，无需依赖应用层

  • 可以通过重写HttpSession、或者Tomcat的Session机制，来实现无侵入的Session共享

  • 通常使用Redis作为存储引擎

• 基于Cookie机制

  • 生成Token，写入Cookie中，每次请求浏览器将会带着Token到服务端

  • 服务端根据Token识别用户的状态

  • 此方式实现简单、不影响服务端性能，但是具有安全问题

基于Cookie机制

JWT

jwt是一种令牌机制，目前共有两种令牌类型：

• 透明令牌

  • By Reference Token

  • 随机字符串，无法猜测，严格服务器集中校验

• 自包含令牌

  • By Value Token

  • 可以包含用户元数据或者声明(claims)，无状态校验

  • 如，JSON Web Token

JSON Web Token，是客户端和服务端信息安全传递以及身份认证的一种解决方案。JWT由三个部分组成：

• header

• playload

• signature

所以，JWT的格式通常如下：

xxxxx.yyyyy.zzzzz

// 比如
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header：

{
  "alg": "HS256", // 使用的签名算法
  "typ": "JWT" // token的类型
}

此部分经过Base64编码称为JSON Web Token的第一部分。

Payload：

Payload可以称为 载荷，用于承载具体的数据，包含实体数据。其中包含 claims，是对数据的声明，共有三种类型：

• Registered claims：已注册Claims，是一组预定义的声明，非强制，但是不强制使用。包含 iis(发行人)、exp(到期时间)、sub(主题)、aud(观众)等。

• Public claims：由使用JWT的人随意定义。

• Private claims：

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

然后，Payload经过Base64Url编码，形成JSON Web Token 的第二部分。

Signature：

生成签名，由 encode header . encode payload 使用 header的alg 签名算法与指定的secret进行签名。从而保证信息不被篡改、发件人是否属实。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

认证流程

1. 客户端登录、服务端生成Token

2. 服务端将Token返回给客户端，客户端存储Token到Cookie或者localstorage中

3. 客户端携带token调用api，校验token并处理响应

4. 为了保证Token的有效性，需要制定Token刷新机制

JWT 优劣

优点：

• CORS

• 不需要CSRF保护

• 无状态校验

  • 不需要分布式存储

  • 减少服务器压力

缺点：

• 信息公开可见

• 易受XSS攻击

• 可能包含过期授权信息

• 令牌大小随信息量增长

• 无状态与吊销互斥

如果需要更严格的方式，需要使用透明令牌+集中校验的方式。