session、token、JWT的一文详细介绍

一、认证Authentication

认证就是验证当前用户的身份，证明身份

• 认证的应用
  • 用户密码登录
  • 邮箱发送登录链接
  • 手机号接收验证码

二、授权Authorization

授权就是用户授予第三方应用访问用户某些资源的权限

• 授权的应用
  • 手机第三方app询问是否授权（访问相册、地理位置等权限）
  • 访问微信小程序，登录的时候会询问是否允许授权（获取昵称、头像、地区、性别等个人信息）
• 实现方式
  • cookie
  • session
  • token

三、凭证Credentials

实现认证和授权的前提是需要一种媒介证书来标记访问者的身份

• 凭证的应用
  • 居民身份证，通过身份证可以实现办理手机卡/银行卡/个人贷款，这就是认证的凭证
  • 互联网两种模式：①游客模式：可以浏览文章，但不可以点赞评论转发②登录模式：注册登录账号，登陆后浏览器发一个token来证明你的身份。每次浏览器请求都会带上token，可以使用登录模式下点赞评论转发功能。

四、session

4.1 什么是session

客户端请求服务端，服务端会为这次请求开辟一个内存空间，这个对象是session对象，存储数据结构为ConcurrentHashMap

session弥补HTTP无状态，服务端利用session在客户端存储会话记录操作。

session是一种记录服务器和服务端会话状态的机制。

session基于cookie实现，session存储在服务端，sessionid存储到客户端的cookie中

4.2 session如何判断是否是同一个会话

①服务器第一次接收到请求，创建session对象，开辟一块内存空间session空间，同时生成sessionid

②通过响应头的’Set-Cookie：JSESSIONID=XXXXXXX '命令，向客户端发送要求设置cookie的响应

③客户端接收到响应后，在本机客户端设置一个’JSESSIONID=XXXXXXX’的Cookie信息，该Cookie的浏览器会话结束存储过期

④接下来客户端每一次发送请求，请求头都会带上cookie信息（含sessionid）

⑤服务器通过读取请求头中的cookie信息，获得sessionid的值，判断属于哪一个用户。

4.3 session认证流程

sessionid是连接cookie和session的桥梁，这个原理也是大部分判断用户登录状态的机制

（1）用户第一次请求服务器，服务器根据用户提交的相关信息，创建session对象，开辟内存空间

（2）请求返回session唯一标识sessionid给浏览器

（3）浏览器收到sessionid信息后存储在cookie中，同时cookie会记录这个sessionid属于哪一个域名

（4）用户第二次请求服务器，请求自动判断这个域名下是否存在cookie信息。如果存在自动将cookie信息发送给服务端，服务端从cookie中获取sessionid，根据sessionid查找session信息。如果不存在则说明用户没有登录或者登录失败。

4.4 session存在的问题

（1）session存储在服务器，在线用户多的时候，session占据内存较多，需要定期清理内存

（2）移动端对cookie兼容支持不高，session需要cookie实现。移动端用token较多。

（3）A 服务器存储了 Session，就是做了负载均衡后，假如一段时间内 A 的访问量激增，会转发到 B 进行访问，但是 B 服务器并没有存储 A 的 Session，会导致 Session 的失效。后端需要多台服务器支持前端大量用户的请求，用户在服务器A登录，第二次请求跑到服务器B就会登陆实现。（解决办法：Nginx ip_hash策略、Session策略、共享Session）

五、token

5.1 什么是token

token是在客户端频繁向服务端请求数据，服务端频繁区数据库查询比对用户名和密码，判断是否正确并做出相对应的提示。

基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库。

token 完全由应用管理，所以它可以避开同源策略

token组成=uid（用户唯一身份标识）、time（当前时间的时间戳）、sign（签名）

token也是用hash算法，前几位压缩成一定长度的十六进制字符串

5.2 Access Token

token是令牌，包括access token和refresh token

• Access Token特点
  • 服务端无状态、可扩展性良好
  • 支持移动设备，移动端常用token
  • 安全
  • 可以跨程序调用

5.3 AccessToken身份认证流程

①客户端使用用户名和密码请求登录

②服务端收到请求，验证用户名和密码

③验证成功后，服务端签发一个token，发给客户端

④客户端接收token，存储token，存储在cookie里或者localStorage里

⑤客户端每次发送请求都需要携带服务端签发的token（放在http的header里）

⑥服务端收到请求后，需要验证请求里的token，验证成功返回数据

5.4 Refresh token

access token有效期比较短，而且每次刷新access token的时候都要输入登录用户名和密码，是不是很麻烦！所以 refresh token就出现了。refresh token的有效期比较长，使用refresh token 就可以获取到新的 token。客户端直接用refresh token更新access token，无需用户任何操作。如果refresh token也过了有效期，那么就需要重新登录。

refresh token 及过期时间是存储在服务器的数据库中，只有在申请新的 Acesss Token 时才会验证，不会对业务接口响应时间造成影响，也不需要向 Session 一样一直保持在内存中以应对大量的请求。

refresh token是专门用来刷新access token的token

5.5 Refresh Token验证流程

六、JWT-JSON Web Token

6.1 什么是JWT

JWT-JSON Web Token是目前最流行的跨域认证解决方案，是一种认证授权机制

JWT 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准。JWT 的声明一般被用来在身份提供者和服务器提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。

可以用HMAC算法或者RSA的公钥密钥对JWT进行数字签名。

6.2 JWT的原理

6.3 JWT认证流程

①用户输入用户名/密码登录，服务端认证成功后，会返回客户端一个JWT

②客户端将token保存在本地（通常是localStorage/cookie）

③用户访问一个受保护的资源或者路由的时候，请求头的Authorization字段中使用Bearer模式添加JWT

Authorization: Bearer <token>

• 服务端的保护路由将会检查请求头Authorization中的JWT信息，如果合法，允许用户行为
• JWT包含内部会话信息，因此减少查询数据库的需要
• JWT不使用cookie，所以使用任何域名提供的API服务不需要担心跨域资源共享问题（CORS）
• 用户的状态不再存储在服务端内存中，所以是一种无状态的认证机制
• 和多个服务器只需要共享密钥就可以让多个服务器具备验证能力，解决cookie不能跨域问题

6.4 JWT的使用方式

客户端收到服务器返回的JWT，存储在cookie里面，或者localStorage里面

（1）方式一

用户希望访问一个受保护的路由或者资源，可以把JWT放在cookie里面自动发送，但是这样不能解决跨域问题。

做法是放在HTTP请求头信息的Authorization 字段里，使用 Bearer 模式添加 JWT

GET /calendar/v1/events
Host: api.example.com
Authorization: Bearer <token>

（2）方式二

跨域的时候，可以把JWT放在POST请求的数据体里

（3）方式三

通过URL传输

http://www.example.com/user?token=xxx

6.5 JWT过程

用户发送请求，用户信息传递到服务端的时候，服务器不再像以前一样存储在session中，而是将浏览器发送过来的内容通过内部的密钥将信息加密，使用SHA256和RSA等加密算法生成一个token令牌和用户信息一起返回给浏览器，当涉及用户验证的所有请求只需要将这个token的信息和用户信息发送给服务器，而服务器将用户信息和自己的密钥通过算法进行签名，将客户端发送的签名和生成的比较，严格相等，则证明用户信息没有被篡改和改造，验证通过。

6.6 JWT的结构

JWT作为声明传递的标准是因为它有自己的结构

JWT生成token有三部分组成，每一个部分用 . 隔开

（1）Header

Header有两部分组成

①token类型

②加密算法

{typ:'jwt',alg:'HS256'}//HS256 就是指 sha256 算法，会将这个对象转成 base64

（2）Payload

负载就是存放有效信息的地方，有效信息被分为标准注册的声明、公有的声明、私有的声明

• 注册的声明

  • iss：jwt 签发者
  • sub：jwt 所面向的用户
  • aud：接收 jwt 的一方
  • exp：jwt 的过期时间，这个过期时间必须要大于签发时间，这是一个秒数。常用
  • nbf：定义在什么时间之前，该 jwt 都是不可用的。常用
  • iat：jwt 的签发时间

• 公有声明

可以添加任何信息，一般添加用户的相关信息或者其他业务需要的必要信息，因为是公有不建议添加敏感信息。

该部分在客户端解密

{"id", username: "gaby", adress: "wang"}//将对象转成base64

• 私有声明

私有声明是提供者和消费者所共同定义的声明，也不建议放敏感信息，因为base64是对称解密。

（3）Signature

Signature是指将Header和Payload通过密钥secret和加密算法生成的签名

secret密钥保存在服务端，不会发送给任何人，很安全，JWT传输方式是安全的

将Header+Payload+Signature连接成字符串返回给浏览器token，浏览器将这个token存储在cookie或者localStorage，用于验证

私有声明是提供者和消费者所共同定义的声明，也不建议放敏感信息，因为base64是对称解密。

（3）Signature

Signature是指将Header和Payload通过密钥secret和加密算法生成的签名

secret密钥保存在服务端，不会发送给任何人，很安全，JWT传输方式是安全的

将Header+Payload+Signature连接成字符串返回给浏览器token，浏览器将这个token存储在cookie或者localStorage，用于验证。
后续
在这篇笔记中整理了session、token、JWT的基本知识。下一篇笔记中会详细整理session、token、JWT有什么比较区别、分别都应用于哪一些场景，各自的优缺点是什么。