会话技术及用户认证-Cookie、Session与 Token_expires: tokencookieexpires,-优快云博客

前言

最早互联网只是用于简单的浏览文档信息、查看黄页及门户网站等等，并没有交互这个说法。但是随着互联网慢慢发展，宽带、服务器等硬件设施得到了很大的提示，互联网允许人们可以做更多的事情，所以交互式Web逐渐兴起，而HTTP无状态的特点却严重阻碍了其发展。
HTTP 是无状态的协议，每个请求都是完全独立的（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）。也就是说，无法根据之前的状态进行本次的请求处理——服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。
因此，服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。

Cookie

在1994年，网景公司将Cookie的概念应用于网络通信，用来解决用户网上购物的购物车历史记录问题。而当时最强大的浏览器正是网景浏览器，在其支持下，其它浏览器也渐渐开始支持Cookie，到目前当然所有的浏览器都支持Cookie了。

既然Web服务器记不住东西，那么我们就在外部想办法记住，相当于服务器给每个客户端都贴上了一个小纸条。上面记录了服务器给我们返回的一些信息。然后服务器看到这张小纸条就知道我们是谁了，这个小纸条也就是Cookie。

Cookie是由服务器产生的而保存在客户端的一些数据，一般通过HTTP响应头Set-Cookie来设置，当然也可以通过JS脚本来直接设置，Cookie是按照网站来进行组织和保存的，每一个网站都可以在浏览器中保存一些Cookie，保存好了之后，浏览器向这个网站发出的请求都会携带这些Cookie，用于服务器记录客户端的状态。
例如，当我们登录网站勾选保存用户名和密码的时候，一般保存的都是cookie，将用户名和密码的cookie保存下来，这样再次登录的时候浏览器直接将cookie发送到服务端验证，直接username和password保存到客户端；再比如用户喜欢的网页背景色，这些信息也是可以通过Cookie保存到客户端的，这样登录之后直接浏览器直接就可以拿到相应的偏好设置。
Cookie主要用于以下三个方面：

会话状态管理：如用户登陆状态、购物车商品或其它需要记录的信息
个性化设置：如用户自定义设置、主题等
浏览器行为跟踪：如跟踪分析用户行为等

构成

cookie遵循name=value格式的字符串形式，并且单个cookie保存的数据不能超过4K（很多浏览器都限制一个站点最多保存20个cookie）。主要构成有：

name: 一个唯一确定的cookie名称，服务器就是通过name属性来获取某个cookie值。通常来讲cookie的名称是不区分大小写的。

value: 存储在cookie中的字符串值，大多数情况下服务器会把这个value当作一个key取缓存中查询保存的数据。最好为cookie的name和value进行url编码

domain: cookie对于哪个域是有效的。所有向该域发送的请求中都会包含这个cookie信息。顶级域名（如 .baidu.com）只能设置或访问顶级域名的Cookie，二级及二级以下域名（ tieba.baidu.com）可以访问或设置自身或者顶级域名的Cookie（也就是说，如果要在多个二级域名中共享Cookie，只能将domain属性设置为顶级域名）。

path:  表示这个cookie影响到的路径，浏览器跟会根据这项配置，像指定域中匹配的路径发送cookie（只有该路径下的页面可以读取此cookie)。

expires: 失效时间，表示cookie何时应该被删除的时间戳(也就是，何时应该停止向服务器发送这个cookie)。如果不设置这个时间戳，浏览器会在页面关闭时即将删除所有cookie；不过也可以自己设置删除时间。这个值是GMT时间格式，如果客户端和服务器端时间不一致，使用expires就会存在偏差。

max-age:  与expires作用相同，用来告诉浏览器此cookie多久过期（单位是秒），而不是一个固定的时间点。正常情况下，max-age的优先级高于expires。

HttpOnly:  告知浏览器不允许通过脚本document.cookie去更改这个值，同样这个值在document.cookie中也不可见。但在http请求张仍然会携带这个cookie。注意这个值虽然在脚本中不可获取，但仍然在浏览器安装目录中以文件形式存在。这项设置通常在服务器端设置。

secure:  安全标志，指定后，只有在使用SSL链接时候才能发送到服务器，如果是http链接则不会传递该信息。就算设置了secure 属性也并不代表他人不能看到你机器本地保存的 cookie 信息，所以不要把重要信息放cookie就对了。

会话cookie和持久cookie

cookie有过期时间设定。
如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。
存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。

Session

Cookie是存在客户端，且其本身存储的尺寸大小有限，最关键的问题是Cookie是用户可见的，并可以随意地修改，安全性存在很大问题。为了安全又方便地全局读取信息，一种新的存储会话机制——Session诞生了。
session是服务端存储的一个对象，主要用来存储所有访问过该服务端的客户端的用户信息（也可以存储其他信息），从而实现保持用户会话状态。但是服务器重启时，内存会被销毁，存储的用户信息也就消失了。
不同的用户访问服务端的时候会在session对象中存储键值（key-vaule）对，key是用来存储开启这个用户信息的“钥匙”，在登录成功后，“钥匙”通过cookie返回给客户端，客户端存储为session Id记录在cookie中。当客户端再次访问时，会默认携带cookie中的session Id来实现会话机制。
简单来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时由于在服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的。

Session认证流程

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

若浏览器禁止cookie，可以通过URL重写的方式发送：把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

分布式架构下 session 共享方案

Session的数据一般是存储到内存中，那问题就来了，如果我们的服务是分布式部署，有多台机器的话，可能我们第一次登陆的时候，我们把用户的信息存储到了session，但是后面的请求到了B机器上，那B机器是获取不到用户的session的。另外就是Session存储在内存中，那服务器重启，Session就丢失了，这就是它的弊端。现在有一些技术可以解决上述问题。
1. session 复制
任何一个服务器上的 session 发生改变（增删改），该节点会把这个 session 的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要 session ，以此来保证 session 同步。

优点：可容错，各个服务器间 session 能够实时响应。
缺点：会对网络负荷造成一定压力，如果 session 量大的话可能会造成网络堵塞，拖慢服务器性能。

2. 粘性 session /IP 绑定策略
采用 Ngnix 中的 ip_hash 机制，将某个 ip的所有请求都定向到同一台服务器上，即将用户与服务器绑定。用户第一次请求时，负载均衡器将用户的请求转发到了 A 服务器上，如果负载均衡器设置了粘性 session 的话，那么用户以后的每次请求都会转发到 A 服务器上，相当于把用户和 A 服务器粘到了一块，这就是粘性 session 机制。

优点：简单，不需要对 session 做任何处理。
缺点：缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的 session 信息都将失效。
适用场景：发生故障对客户产生的影响较小；服务器发生故障是低概率事件。
实现方式：以 Nginx 为例，在 upstream 模块配置 ip_hash 属性即可实现粘性 session。

3. session 共享（常用）
使用分布式缓存方案比如 Memcached 、Redis 来缓存 session，但是要求 Memcached 或 Redis 必须是集群。把 session 放到 Redis 中存储，虽然架构上变得复杂，并且需要多访问一次 Redis ，但是这种方案带来的好处也是很大的：

实现了 session 共享；
可以水平扩展（增加 Redis 服务器）；
服务器重启 session 不丢失（不过也要注意 session 在 Redis 中的刷新/失效机制）；
不仅可以跨服务器 session 共享，甚至可以跨平台（例如网页端和 APP 端）

4. session 持久化
将 session 存储到数据库中，保证 session 的持久化

优点：服务器出现问题，session 不会丢失
缺点：如果网站的访问量很大，把 session 存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。

Cookie和Session的区别

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗,考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上，当访问增多，会比较占用服务器的性能。考虑到减轻服务器负担方面，应当使用cookie。
4、存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。

因此，通常的做法是，将登陆信息等重要信息存放为session，而其他信息如果需要保留，可以放在cookie中。

Token

session 是保存了会话的链接信息与需要传输的内容，容量大，还需要保持会话信息，每次同一用户不同客户端访问都需要重新建立session，造成冗余信息大。
Token的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。当用户第一次登录后，服务器生成一个token并将此token返回给客户端，以后客户端只需带上这个token前来请求数据即可，无需再次带上用户名和密码。

token 的身份验证流程

1、客户端使用用户名跟密码请求登录
2、服务端收到请求，去验证用户名与密码
3、验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
4、客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 LocalStorage 里
5、客户端每次向服务端请求资源的时候需要带着服务端签发的 token
6、服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据
在这个过程中，每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里。
基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库。token 完全由应用管理，所以它可以避开同源策略。

Token 和 Session 的区别

1、Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。Token 使服务端无状态化，不会存储会话信息。
2、Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。
3、所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SessionID 的不可预测性，暂且认为是安全的。而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是认证和授权，认证是针对用户，授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上，也不可以转到其它用户上。Session 只提供一种简单的认证，即只要有此 SessionID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方 App。

Token的特点

Token的特点
• 随机性：每次的token都是不一样的
• 不可预测性：没有规律，无法预测
• 时效性：可以设置token的有效时间
• 无状态、可扩展：由于只是一个算法，扩展起来非常方便
生成Token的解决方案有许多，常用的一种就是 JSON Web Token(JWT) .

JWT

JWT是目前最流行的跨域认证解决方案,可以使用在RESTFUL接口定义，也可以使用在普通的web。它将用户信息加密到token里，服务器不保存任何用户信息。服务器通过使用保存的密钥验证token的正确性，只要正确即通过验证。
JWT标准的Token由三部分组成：Header头部，Payload负载和Signature签名，三部分之间用“.”号做分割。
1、Header 声明信息。在Header中通常包含了两部分：type：代表token的类型，这里使用的是JWT类型。 alg:使用的Hash算法，例如HMAC SHA256或RSA。{ “alg”: “HS256”, “typ”: “JWT” } 这会被经过Base64 URL编码形成第一部分

2、Payload token的第二个部分是荷载信息，它包含一些声明Claim(实体的描述，通常是一个User信息，还包括一些其他的元数据) 声明分三类:
1)Reserved Claims：这是一套预定义的声明，并不是必须的,这是一套易于使用、操作性强的声明。包括：iss(issuer)、exp(expiration time)、sub(subject)、aud(audience)等
2)Plubic Claims
3)Private Claims：交换信息的双方自定义的声明 { “sub”: “1234567890”, “name”: “John Doe”, “admin”: true }
默认情况下JWT是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息（当然加密也没问题）加密的话推荐使用RSA加密。JSON对象也使用Base64 URL算法转换为字符串保存。

3、Signature 使用header中指定的算法将编码后的header、编码后的payload、一个secret进行加密。例如使用的是HMAC SHA256算法，大致流程类似于: HMACSHA256( base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret) 。这个signature字段被用来确认JWT信息的发送者是谁，并保证信息没有被修改。

验证流程：

1. 在头部信息中声明加密算法和常量， 然后把header使用json转化为字符串
2. 在载荷中声明用户信息，同时还有一些其他的内容；再次使用json 把载荷部分进行转化，转化为字符串
3. 使用在header中声明的加密算法和每个项目随机生成的secret来进行加密， 把第一步分字符串和第二部分的字符串进行加密， 生成新的字符串，此字符串是独一无二的。
4. 解密的时候，只要客户端带着JWT来发起请求，服务端就直接使用secret进行解密；解签证解出第一部分和第二部分，然后比对第二部分的信息和客户端穿过来的信息是否一致。如果一致验证成功，否则验证失败。

常见问题总结补充

使用 cookie 时需要考虑的问题

因为存储在客户端，容易被客户端篡改，使用前需要验证合法性
不要存储敏感数据，比如用户密码，账户余额
使用 httpOnly 在一定程度上提高安全性
尽量减少 cookie 的体积，能存储的数据量不能超过 4kb
设置正确的 domain 和 path，减少数据传输
cookie 无法跨域
一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie
移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 session 时需要考虑的问题

将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session
当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的，但是处理用户请求的服务器不一定是那个创建 session 的服务器，那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。
当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。
sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie 怎么办？一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现
移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 token 时需要考虑的问题

如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。
token 完全由应用管理，所以它可以避开同源策略
token 可以避免 CSRF 攻击(因为不需要 cookie 了)
移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

JWT相关

因为 JWT 并不依赖 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
JWT 不加密的情况下，不能将秘密数据写入 JWT。
JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
JWT 最大的优势是服务器不再需要存储 Session，使得服务器认证鉴权业务可以方便扩展。但这也是 JWT 最大的缺点：由于服务器不需要存储 Session 状态，因此使用过程中无法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了，到期之前就会始终有效，除非服务器部署额外的逻辑。
JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
JWT 适合一次性的命令认证，颁发一个有效期极短的 JWT，即使暴露了危险也很小，由于每次操作都会生成新的 JWT，因此也没必要保存 JWT，真正实现无状态。
为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。