Cookie、Session、Token那点事儿和先后端分离之JWT用户认证

（两篇文章转自：https://www.jianshu.com/p/bd1be47a16c1；https://www.jianshu.com/p/180a870a308a）

什么是Cookie？

Cookie 技术产生源于 HTTP 协议在互联网上的急速发展。随着互联网时代的策马奔腾，带宽等限制不存在了，人们须要更复杂的互联网交互活动，就必须同服务器保持活动状态（简称：保活）。因而，在浏览器发展初期，为了适应用户的需求技术上推出了各类保持 Web 浏览状态的手段，其中就包括了 Cookie 技术。Cookie 在计算机中是个存储在浏览器目录中的文本文件，当浏览器运行时，存储在 RAM 中发挥做用 （此种 Cookies 称做 Session Cookies），一旦用户从该网站或服务器退出，Cookie 可存储在用户本地的硬盘上 （此种 Cookies 称做 Persistent Cookies）。

Cookie 起源：1993 年，网景公司雇员 Lou Montulli 为了让用户在访问某网站时，进一步提升访问速度，同时也为了进一步实现我的化网络，发明了今天普遍使用的 Cookie。（因此，适当的偷懒也会促进人类计算机发展史的一小步~）

Cookie时效性：目前有些 Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间，一旦超过规定的时间，该 Cookie 就会被系统清除。

Cookie使用限制：Cookie 必须在 HTML 文件的内容输出以前设置；不一样的浏览器 (Netscape Navigator、Internet Explorer) 对 Cookie 的处理不一致，使用时必定要考虑；客户端用户若是设置禁止 Cookie，则 Cookie 不能创建。 而且在客户端，一个浏览器能建立的 Cookie 数量最多为 300 个，而且每一个不能超过 4KB，每一个 Web 站点能设置的 Cookie 总数不能超过 20 个。

执行流程：

A：首先，客户端会发送一个http请求到服务器端。

B： 服务器端接受客户端请求后，发送一个http响应到客户端，这个响应头，其中就包含Set-Cookie头部。

C：在客户端发起的第二次请求（注意：若是服务器须要咱们带上Cookie，咱们就须要在B步骤上面拿到这个Cookie而后做为请求头一块儿发起第二次请求），提供给了服务器端能够用来惟一标识客户端身份的信息。这时，服务器端也就能够判断客户端是否启用了cookies。尽管，用户可能在和应用程序交互的过程当中忽然禁用cookies的使用，可是，这个状况基本是不太可能发生的，因此能够不加以考虑，这在实践中也被证实是对的。

为了方便理解，能够先看下这张流程执行图加深概念

 

客户端与服务端的Cookie流程图

那么，在浏览器上面的请求头和Cookie在那？下图给你们截取了其中一种。

 

请求头上面的Cookie

那么，上面都是谈浏览器上的Cookie，那么在Android开发中，咱们该如何去管理和使用Cookie？Okhttp做为经典到爆的网络框架，它的API（本文是基于Okhttp3.0版本以上，3.0如下的版本API有所不一样）是经过OkhttpClient中的CookieJar或者拦截器去管理Cookie的。理论上，咱们只需在构建单例OkhttpClient的时候，设置cookiejar或者拦截器，而后具体的操做（具体的操做也就是保存Cookie，取Cookie），Okhttp框架就会帮咱们自动管理Cookie。以下图：

 

OKhttp的管理策略

这是其中一种经过集合的增查特性，就能够简单有效的帮咱们管理Cookie。但咱们仍是要经过源代码去一探究竟。首先，CookieJar是一个接口。

 

CookieJar

英文注释翻译过来就是（对应段落翻译）：

CookieJar这个接口为HTTP cookies提供了强大的支持和相关策略。

这种策略的实现做用会负责选择接受和拒绝那些cookie。一个合理的策略是拒绝全部的cookie，尽管这样会干扰须要cookie的基于会话的自身身份验证方案。

做为Cookie的持久性，该接口的实现也必需要提供Cookie的存储。一种简单的实现能够将cookie存储在内存中;复杂的系统可使用文件系统用于保存已接受的cookie的数据库。这里的连接指定cookie存储模型更新和过时的cookie的策略。

因此，Okhttp的源码告知咱们能够将cookie存储在内存中;复杂的系统可使用文件系统用于保存已接受的cookie的数据库。所以，咱们就能够经过Map去简单的管理和使用。

继续分析CookieJar接口里面的方法，依旧上源码

 

CookieJar里面的方法

里面有方法一个是saveFromResponse(HttpUrl url, List cookies)、loadForRequest(HttpUrl url)

saveFromResponse方法翻译：根据这个jar的方法，能够将cookie从一个HTTP响应保存到这里。请注意，若是响应，此方法可能被称为第二次HTTP响应，包括一个追踪。对于这个隐蔽的HTTP特性，这里的cookie只包含其追踪的cookie。简单点理解就是若是咱们使用了这个方法，就会进行追踪（说白了就是客户端请求成功之后，在响应头里面去存cookie）

loadForRequest方法翻译：将cookie从这个方法加载到一个HTTP请求到指定的url。这个方法从网络上返回的结果多是一个空集合。简单的实现将返回还没有过时的已接受的cookie去进行匹配。（说白了就是加载url的时候在请求头带上cookie）。

 

经过CookieJar打印Cookie信息

这样，咱们经过以上代码就能够完成了Cookie的非持久化。什么，非持久化，这又是神马？

继续给你们科普，在上面说道，Cookie是具备时效性的，因此，Cookie的管理又分为持久化Cookie和非持久化Cookie。非持久化Cookie存储在内存中，也就意味着，其生命周期基本和app保持一致,app关闭后，Cookie丢失。而持久化Cookie则是存储在本地磁盘中，app关闭后不丢失。那么，若是咱们要使用Cookie的持久化策略，思想能够参考上面的非持久化策略，只须要将存储方式改一下便可：

A：经过响应拦截器从response取出cookie并保存到本地，经过请求拦截器从本地取出cookie并添加到请求中

B：自定义CookieJar，在saveFromResponse()中保存cookie到本地，在loadForRequest()从本地取出cookie。

那么在这里主要介绍如何经过Okhttp逼格值较高的拦截器去进行持久化cookie操做。（拦截器源码见文章末尾处）

 

保存cookie拦截器-1

 

 

保存cookie拦截器-2

这个SaveCookiesInterceptor拦截器的实现，是首先从response获取set-cookie字段的值，而后经过SharedPreferences保存在本地。

 

将Cookie添加到请求头

AddCookiesInterceptor请求拦截器，这个拦截的做用就是判断若是该请求存在cookie，则为其添加到Header的Cookie中。

写好这两个拦截器以后，咱们只须要将实例对象放进OkhttpClient里面便可快速的完成Cookie持久化操做。（PS：这两个拦截器在同步Cookie的时候也是超级好用）。

 

Okhttp使用cookie拦截器

拓展：如何经过客户端的cookie与H5上面的cookie进行同步，针对这个问题，给你们推荐笔者的另一篇文章

客户端与H5同步Cookie

Session :

Session是对于服务端来讲的，客户端是没有Session一说的。Session是服务器在和客户端创建链接时添加客户端链接标志，最终会在服务器软件（Apache、Tomcat、JBoss）转化为一个临时Cookie发送给给客户端，当客户端第一请求时服务器会检查是否携带了这个Session（临时Cookie），若是没有则会添加Session，若是有就拿出这个Session来作相关操做。

在这里引用别人家的一个小故事来加深印象：

        在说session是啥以前，咱们先来讲说为何会出现session会话，它出现的机理是什么？    咱们知道，咱们用浏览器打开一个网页，用到的是HTTP协议，了解计算机的应该都知道这个协议，它是无状态的，什么是无状态呢？就是说这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。可是这种无状态的的好处是快速。因此就会带来一个问题就是，我但愿几个请求的页面要有关联，好比：我在www.a.com/login.php里面登录了，我在www.a.com/index.php 也但愿是登录状态，可是，这是2个不一样的页面，也就是2个不一样的HTTP请求，这2个HTTP请求是无状态的，也就是无关联的，因此没法单纯的在index.php中读取到它在login.php中已经登录了！        那咋搞呢？我不可能这2个页面我都去登录一遍吧。或者用笨方法这2个页面都去查询数据库，若是有登录状态，就判断是登录的了。这种查询数据库的方案虽然可行，可是每次都要去查询数据库不是个事，会形成数据库的压力。 因此正是这种诉求，这个时候，一个新的客户端存储数据方式出现了：cookie。cookie是把少许的信息存储在用户本身的电脑上，它在一个域名下是一个全局的，只要设置它的存储路径在域名www.a.com下 ，那么当用户用浏览器访问时，php就能够从这个域名的任意页面读取cookie中的信息。因此就很好的解决了我在www.a.com/login.php页面登录了，我也能够在www.a.com/index.php获取到这个登录信息了。同时又不用反复去查询数据库。 虽然这种方案很不错，也很快速方便，可是因为cookie 是存在用户端，并且它自己存储的尺寸大小也有限，最关键是用户能够是可见的，并能够随意的修改，很不安全。那如何又要安全，又能够方便的全局读取信息呢？因而，这个时候，一种新的存储会话机制：session 诞生了。      Session 就是在一次会话中解决2次HTTP的请求的关联，让它们产生联系，让2两个页面都能读取到找个这个全局的session信息。session信息存在于服务器端，因此也就很好的解决了安全问题。

Token :

token是用户身份的验证方式，咱们一般叫它：令牌。最简单的token组成:uid(用户惟一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成必定长的十六进制字符串，能够防止恶意第三方拼接token请求服务器)。还能够把不变的参数也放进token，避免屡次查库。

应用场景：

A：当用户首次登陆成功（注册也是一种能够适用的场景）以后, 服务器端就会生成一个 token 值，这个值，会在服务器保存token值(保存在数据库中)，再将这个token值返回给客户端.

B：客户端拿到 token 值以后,进行本地保存。（SP存储是你们可以比较支持和易于理解操做的存储）

C：当客户端再次发送网络请求(通常不是登陆请求)的时候,就会将这个 token 值附带到参数中发送给服务器.

D：服务器接收到客户端的请求以后,会取出token值与保存在本地(数据库)中的token值作对比

对比一：若是两个 token 值相同， 说明用户登陆成功过!当前用户处于登陆状态!

对比二：若是没有这个 token 值, 则说明没有登陆成功.

对比三：若是 token 值不一样: 说明原来的登陆信息已经失效,让用户从新登陆.

 

Cookie和Session的区别：

一、cookie数据存放在客户的浏览器上，session数据放在服务器上。

二、cookie不是很安全，别人能够分析存放在本地的cookie并进行cookie欺骗,考虑到安全应当使用session。

三、session会在必定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。

四、单个cookie保存的数据不能超过4K，不少浏览器都限制一个站点最多保存20个cookie。

五、因此我的建议：

将登录信息等重要信息存放为session

其余信息若是须要保留，能够放在cookie中

Token 和 Session 的区别：

session和 token并不矛盾，做为身份认证token安全性比session好，由于每一个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通信安全了。如上所说，若是你须要实现有状态的会话，仍然能够增长session来在服务器端保存一些状态

App一般用restful api跟server打交道。Rest是stateless的，也就是app不须要像browser那样用cookie来保存session,所以用session token来标示本身就够了，session/state由api server的逻辑处理。若是你的后端不是stateless的rest api,那么你可能须要在app里保存session.能够在app里嵌入webkit,用一个隐藏的browser来管理cookie session.

Session是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。所谓Session认证只是简单的把User信息存储到Session里，由于SID的不可预测性，暂且认为是安全的。这是一种认证手段。而Token，若是指的是OAuth Token或相似的机制的话，提供的是 认证 和 受权 ，认证是针对用户，受权是针对App。其目的是让 某App有权利访问 某用户 的信息。这里的Token是惟一的。不能够转移到其它App上，也不能够转到其它 用户 上。转过来讲Session。Session只提供一种简单的认证，即有此SID，即认为有此User的所有权利。是须要严格保密的，这个数据应该只保存在站方，不该该共享给其它网站或者第三方App。因此简单来讲，若是你的用户数据可能须要和第三方共享，或者容许第三方调用API接口，用Token。若是永远只是本身的网站，本身的App，用什么就无所谓了。

token就是令牌，好比你受权（登陆）一个程序时，他就是个依据，判断你是否已经受权该软件；cookie就是写在客户端的一个txt文件，里面包括你登陆信息之类的，这样你下次在登陆某个网站，就会自动调用cookie自动登陆用户名；session和cookie差很少，只是session是写在服务器端的文件，也须要在客户端写入cookie文件，可是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。

---

 

在先后端分离开发时为何须要用户认证呢？缘由是因为HTTP协定是不储存状态的(stateless)，这意味着当咱们透过账号密码验证一个使用者时，当下一个request请求时它就把刚刚的资料忘了。因而咱们的程序就不知道谁是谁，就要再验证一次。因此为了保证系统安全，咱们就须要验证用户否处于登陆状态。

传统方式

先后端分离经过Restful API进行数据交互时，如何验证用户的登陆信息及权限。在原来的项目中，使用的是最传统也是最简单的方式，前端登陆，后端根据用户信息生成一个token，并保存这个 token 和对应的用户id到数据库或Session中，接着把 token 传给用户，存入浏览器 cookie，以后浏览器请求带上这个cookie，后端根据这个cookie值来查询用户，验证是否过时。

但这样作问题就不少，若是咱们的页面出现了 XSS 漏洞，因为 cookie 能够被 JavaScript 读取，XSS 漏洞会致使用户 token 泄露，而做为后端识别用户的标识，cookie 的泄露意味着用户信息再也不安全。尽管咱们经过转义输出内容，使用 CDN 等能够尽可能避免 XSS 注入，但谁也不能保证在大型的项目中不会出现这个问题。

在设置 cookie 的时候，其实你还能够设置 httpOnly 以及 secure 项。设置 httpOnly 后 cookie 将不能被 JS 读取，浏览器会自动的把它加在请求的 header 当中，设置 secure 的话，cookie 就只容许经过 HTTPS 传输。secure 选项能够过滤掉一些使用 HTTP 协议的 XSS 注入，但并不能彻底阻止。

httpOnly 选项使得 JS 不能读取到 cookie，那么 XSS 注入的问题也基本不用担忧了。但设置 httpOnly 就带来了另外一个问题，就是很容易的被 XSRF，即跨站请求伪造。当你浏览器开着这个页面的时候，另外一个页面能够很容易的跨站请求这个页面的内容。由于 cookie 默认被发了出去。

另外，若是将验证信息保存在数据库中，后端每次都须要根据token查出用户id，这就增长了数据库的查询和存储开销。若把验证信息保存在session中，有加大了服务器端的存储压力。那咱们可不能够不要服务器去查询呢？若是咱们生成token遵循必定的规律，好比咱们使用对称加密算法来加密用户id造成token，那么服务端之后其实只要解密该token就能够知道用户的id是什么了。不过呢，我只是举个例子而已，要是真这么作，只要你的对称加密算法泄露了，其余人能够经过这种加密方式进行伪造token，那么全部用户信息都再也不安全了。恩，那用非对称加密算法来作呢，其实如今有个规范就是这样作的，就是咱们接下来要介绍的 JWT。

Json Web Token（JWT）

JWT 是一个开放标准(RFC 7519)，它定义了一种用于简洁，自包含的用于通讯双方之间以 JSON 对象的形式安全传递信息的方法。JWT 可使用 HMAC 算法或者是 RSA 的公钥密钥对进行签名。它具有两个特色：

• 简洁(Compact)

  能够经过URL, POST 参数或者在 HTTP header 发送，由于数据量小，传输速度快

• 自包含(Self-contained)

  负载中包含了全部用户所须要的信息，避免了屡次查询数据库

JWT 组成

 

• Header 头部

头部包含了两部分，token 类型和采用的加密算法

{ "alg": "HS256", "typ": "JWT" }

它会使用 Base64 编码组成 JWT 结构的第一部分,若是你使用Node.js，能够用Node.js的包base64url来获得这个字符串。

Base64是一种编码，也就是说，它是能够被翻译回原来的样子来的。它并非一种加密过程。

• Payload 负载

这部分就是咱们存放信息的地方了，你能够把用户 ID 等信息放在这里，JWT 规范里面对这部分有进行了比较详细的介绍，经常使用的由 iss（签发者），exp（过时时间），sub（面向的用户），aud（接收方），iat（签发时间）。

{ "iss": "lion1ou JWT", "iat": 1441593502, "exp": 1441594722, "aud": "www.example.com", "sub": "lion1ou@163.com" }

一样的，它会使用 Base64 编码组成 JWT 结构的第二部分

• Signature 签名

前面两部分都是使用 Base64 进行编码的，即前端能够解开知道里面的信息。Signature 须要使用编码后的 header 和 payload 以及咱们提供的一个密钥，而后使用 header 中指定的签名算法（HS256）进行签名。签名的做用是保证 JWT 没有被篡改过。

三个部分经过.链接在一块儿就是咱们的 JWT 了，它可能长这个样子，长度貌似和你的加密算法和私钥有关系。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s

其实到这一步可能就有人会想了，HTTP 请求总会带上 token，这样这个 token 传来传去占用没必要要的带宽啊。若是你这么想了，那你能够去了解下 HTTP2，HTTP2 对头部进行了压缩，相信也解决了这个问题。

• 签名的目的

最后一步签名的过程，其实是对头部以及负载内容进行签名，防止内容被窜改。若是有人对头部以及负载的内容解码以后进行修改，再进行编码，最后加上以前的签名组合造成新的JWT的话，那么服务器端会判断出新的头部和负载造成的签名和JWT附带上的签名是不同的。若是要对新的头部和负载进行签名，在不知道服务器加密时用的密钥的话，得出来的签名也是不同的。

• 信息暴露

在这里你们必定会问一个问题：Base64是一种编码，是可逆的，那么个人信息不就被暴露了吗？

是的。因此，在JWT中，不该该在负载里面加入任何敏感的数据。在上面的例子中，咱们传输的是用户的User ID。这个值实际上不是什么敏感内容，通常状况下被知道也是安全的。可是像密码这样的内容就不能被放在JWT中了。若是将用户的密码放在了JWT中，那么怀有恶意的第三方经过Base64解码就能很快地知道你的密码了。

所以JWT适合用于向Web应用传递一些非敏感信息。JWT还常常用于设计用户认证和受权系统，甚至实现Web应用的单点登陆。

JWT 使用

 

1. 首先，前端经过Web表单将本身的用户名和密码发送到后端的接口。这一过程通常是一个HTTP POST请求。建议的方式是经过SSL加密的传输（https协议），从而避免敏感信息被嗅探。

2. 后端核对用户名和密码成功后，将用户的id等其余信息做为JWT Payload（负载），将其与头部分别进行Base64编码拼接后签名，造成一个JWT。造成的JWT就是一个形同lll.zzz.xxx的字符串。

3. 后端将JWT字符串做为登陆成功的返回结果返回给前端。前端能够将返回的结果保存在localStorage或sessionStorage上，退出登陆时前端删除保存的JWT便可。

4. 前端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)

5. 后端检查是否存在，如存在验证JWT的有效性。例如，检查签名是否正确；检查Token是否过时；检查Token的接收方是不是本身（可选）。

6. 验证经过后后端使用JWT中包含的用户信息进行其余逻辑操做，返回相应结果。

和Session方式存储id的差别

Session方式存储用户id的最大弊病在于Session是存储在服务器端的，因此须要占用大量服务器内存，对于较大型应用而言可能还要保存许多的状态。通常而言，大型应用还须要借助一些KV数据库和一系列缓存机制来实现Session的存储。

而JWT方式将用户状态分散到了客户端中，能够明显减轻服务端的内存压力。除了用户id以外，还能够存储其余的和用户相关的信息，例如该用户是不是管理员、用户所在的分组等。虽然说JWT方式让服务器有一些计算压力（例如加密、编码和解码），可是这些压力相比磁盘存储而言可能就不算什么了。具体是否采用，须要在不一样场景下用数听说话。

• 单点登陆

Session方式来存储用户id，一开始用户的Session只会存储在一台服务器上。对于有多个子域名的站点，每一个子域名至少会对应一台不一样的服务器，例如：www.taobao.com，nv.taobao.com，nz.taobao.com，login.taobao.com。因此若是要实如今login.taobao.com登陆后，在其余的子域名下依然能够取到Session，这要求咱们在多台服务器上同步Session。使用JWT的方式则没有这个问题的存在，由于用户的状态已经被传送到了客户端。

总结

JWT的主要做用在于（一）可附带用户信息，后端直接经过JWT获取相关信息。（二）使用本地保存，经过HTTP Header中的Authorization位提交验证。但其实关于JWT存放到哪里一直有不少讨论，有人说存放到本地存储，有人说存 cookie。我的偏向于放在本地存储，若是你有什么意见和见解欢迎提出。

---

综上所述：

一、Cookie：保存在客户端，不是很安全；

二、Session：保存在服务器端，并生成一个Session id保存在客户端。访问过多时会占用服务器的内存和性能；

三、Token：首次登录后，服务器生成Token值，保存在数据库中，再将这个Token值返回给客户端。增长数据库的存储和查询压力；

四、JWT（Json Web Token）：先后端分离项目中使用。根据算法生成，保存在本地。消耗服务器的计算压力。