认证、授权、会话(cookie、session、token)JWT

        HTTP Basic Auth简单点说明就是每次请求 API 时都提供用户的 username 和password，简言之， Basic Auth 是配合RESTful API 使用的最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的 RESTFul API 时，尽量避免采用HTTP Basic Auth。

什么是认证？

认证（Authentication）简单来讲就是验证当前者的身份，验证当前操作人是服务端可信的用户。

最常见的认证方式：用户名和密码，除此之外还有：

• 通过用户手机：短信、语音、二维码扫描、手势等

• 用户的电子邮箱

• 身份证号码

• 自设置的问题与答案

• 基于时间序列和用户相关的一次性口令(银行业务)

• 用户的生物学特征：指纹、语音、眼睛虹膜、人脸等

为了确认用户的身份，防止请求伪造，在安全要求高的场合，经常会使用组合认证（也叫多因素认证），也就是同时使用多个认证方式对用户的身份进行校验。

什么是授权？

授权（Authorization）简单来讲就是授予第三方访问用户资源的权限。

在互联网应用开发中，主要通过下面几种方式实现授权：

• 通过 session 机制，一个访问会话保持着用户的授权信息

• 通过 cookie 机制，一个网站的 cookie 保持着用户的授权信息

• 颁发授权令牌（token），一个合法有效的令牌中保持着用户的授权信息

通过获取用户实际的权限信息，进行拦截和放行、或者关进小黑屋。

什么是 cookie？

Cookie 认证机制就是为一次请求认证在服务端创建一个 Session 对象，同时在客户端的浏览器端创建了一个Cookie 对象；通过客户端带上来 Cookie对象来与服务器端的session 对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候， cookie会被删除。但可以通过修改 cookie 的 expire time 使 cookie 在一定时间内有效；

cookie 的特点

• cookie 最开始被设计出来是为了弥补HTTP在状态管理上的不足。

• cookie 存储在客户端：cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。

• cookie 是不可跨域的：每个 cookie 都会绑定单一的域名（包括子域），无法在别的域名下获取使用。

前端开发者，可能会出现将上一个用户的cookie信息未清除，而绑定了当前用户身上！

设置 cookie

服务器向客户端发送 Cookie 是通过 HTTP 响应报文实现的，在 Set-Cookie 中设置需要向客户端发送的cookie，cookie格式如下：

Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

cookie 大致流程

（1）浏览器向服务器发送请求；

（2）服务器响应请求，向浏览器设置 cookie；

（3）浏览器将 cookie 存在本地，下一次请求带上该 cookie；

（4）服务器响应请求。

不光是浏览器，客户端或者代码里进行相关设置、拦截器进行相关处理的使用场景

cookie 常见属性

（1）name=value

键值对，设置 Cookie 的名称及相对应的值。

（2）domain

指定 cookie 所属域名，默认是当前域名。如果 cookie 的 domain 设置为 taobao.com，那么 item.taobao.com, order.taobao.com 都是可以共享 cookie 的， 但是访问 tmall.com 就不能共享 cookie 了，这就涉及跨域访问的问题，跨域问题如何解决，这里不展开，有兴趣可以自行搜索。

（3）path

指定 cookie 在哪个路径（路由）下生效，默认是 '/'。如果设置为 /abc，则只有 /abc 下的路由可以访问到该 cookie，如：/abc/read。

（4）expires

指定 cookie 的过期时间（GMT时间格式），到达该时间点后该 cookie 就会自动失效。

（5）max-age

HTTP 1.1中定义的，优先级高于 expires 字段。

max-age 表示 cookie 有效期，单位秒。如果为正数，则该 cookie 在 max-age 秒后失效；如果为负数，该 cookie 为临时 cookie ，关闭浏览器即失效，浏览器也不会以任何形式保存该 cookie ；如果为 0，表示删除该 cookie 。默认为 -1。

（6）HttpOnly

如果给某个 cookie 设置了 httpOnly 属性，则无法通过 JS 脚本读写该 cookie 的信息。

（7）secure

该 cookie 是否仅被使用安全协议传输，默认为false。当 secure 值为 true 时，cookie 在 HTTP 中是无效的。

cookie容易被伪造，安全要求的应用没法通过cookie完成安全控制。

什么是 session?

用户打开一个浏览器, 点击多个超链接, 访问服务器一个或者多个web资源, 然后关闭浏览器, 整个过程称之为一个会话。

（1）session 的特点

• session 是另一种记录服务器和客户端会话状态的机制；

• session 存储在服务器端，一般是文件中，也可以存在数据库或缓存中。

• session 一般基于 cookie 实现。session 中包含敏感信息存储在服务器端，通常将 sessionId 存储在客户端的 cookie 中，客户端每次请求携带 sessionId 即可识别用户。

（2）session 工作流程

（1）用户第一次请求，提交用户名密码等信息进行登录认证，服务器根据用户提交的信息进行鉴权，鉴权成功后创建 session 对象，并将 sessionId 塞入 cookie 中，浏览器收到响应信息将 cookie 存入本地；

（2）用户第二次请求，以查看订单信息为例，浏览器自动将当前域名下的 cookie 信息发送给服务端，服务端解析 cookie，获取到 sessionId 后再查找对应的 session 对象，如果 session 对象存在说明用户已经登录，继续下一步操作。

从上面的流程可知，sessionId 是 cookie 和 session 中间的一道桥梁。

需要注意：如果客户端禁用了 cookie，还可以通过 url 重写等方法传递 sessionId。

cookie 和 session 的区别

• 存储方式：cookie 数据存放在客户的浏览器上，session 数据放在服务器上；

• 安全性：cookie 是本地存储，不是很安全，别人可以分析存放在本地的 cookie 并进行欺骗；

• 存储大小：很多浏览器限制单个 cookie 保存的数据不能超过4K，一个站点最多保存20个cookie，session 没有类似的限制；

• 生存周期：cookie 可设置为长时间保持，Session 一般失效时间较短，一般客户端关闭 session 就会失效。

什么是 token ？

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

1. 客户端使用用户名跟密码请求登录

2. 服务端收到请求，去验证用户名与密码

3. 验证成功后，服务端会签发一个 Token ，再把这个 Token 发送给客户端

4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里

5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token

6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据。

（1）token 的组成

token 是验证用户身份的凭证，我们通常叫它：令牌。好比动物园的门票、园区的磁卡等。

最简单的token组成:

id(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，以哈希算法压缩成一定长的十六进制字符串）

（2）token 特点

• 无状态、可扩展

• 支持移动端设备

• 支持跨程序调用

• 安全

（3）token 工作流程

第一步：客户端使用用户名密码或者扫码等形式请求登录；

第二步：服务端收到请求后进行鉴权，鉴权成功后服务端会生成一个 token 并发送给客户端，客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里；

第三步：客户端下一次向服务端请求资源的时候需要带着存储的 token；

第四步：服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据。

需要注意：

• 客户端请求时可以将 token 放到 HTTP 的 Header 里；

• 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。

• 用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

什么是 JWT？

（1）JWT 是标准 化的 token

从本质上讲 JWT 也是一种 token，只不过 JWT 是被大家广泛接受的标准。

JWT 即：Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准(RFC 7519)。

JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息。

（2）JWT 的组成

JWT 共有三部分组成：

• 第一部分我们称它为头部（header)

• 第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)

• 第三部分是签证（signature)

在https://jwt.io/网站上可以解析一个已知的 JWT：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• header头部

jwt的头部承载两部分信息：声明类型，这里是jwt；声明加密的算法,通常直接使用 HMAC SHA256；

• playload载体

载荷存放有效信息。主要包含三个部分：标准中注册的声明；公共的声明；私有的声明。

• signature签名

jwt 的第三部分是一个签名信息，这个签证信息由三部分组成：header (base64后的)；payload (base64后的)；secret。

（3）JWT 的特点

• 不在 jwt 的 payload 部分存放敏感信息，因为该部分是客户端可解密的部分。

• 保护好 secret 私钥，该私钥非常重要。

• 如果可以，请使用 https 协议。

分布式微服务技术日趋流行的今天，大型网站的设计都尽量避免使用 session 实现 HTTP 状态化。

session简单粗暴，在服务端维护会话信息，在客户端保存session id，服务端能够轻易地把会话控制在自己的手中，但服务集群化产生了session共享的负担；

jwt（token）只在客户端保存会话信息，服务端通过密钥校验会话，（相比session）拿时间换空间，卸下了服务端集群共享会话信息的负担，同时也加大了服务端控制会话的难度。

使用他人的门票，进了园区，能感知么？

客户端和服务端互信的操作，想想三次握手...