Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。要跟踪该会话，必须引入一种状态保持机制。 状态保持 修改Http协议，使得它支持状态保持(难做到) Cookies：通过客户端来保持状态信息 Cookie是服务器发给客户端的特殊信息 Cookie是以文本的方式保存在客户端，每次请求时都带上它 Session：通过服务器端来保持状态信息 Session是服务器和客户端之间的一系列的交互动作 服务器为每个客户端开辟内存空间，从而保持状态信息 由于需要客户端也要持有一个标识(id)，因此，也要求服务器端和客户端传输该标识， 标识(id)可以借助Cookie机制或者其他的途径来保存 COOKIE机制 Cookie，有时也用其复数形式Cookies，指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。 由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。 Cookie是由服务器端生成，发送给User-Agent（一般是浏览器），浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用cookie）。Cookie名称和值可以由服务器端开发自己定义，这样服务器可以知道该用户是否是合法用户以及是否需要重新登录等。服务器可以利用Cookies包含信息的任意性来筛选并经常性维护这些信息，以判断在HTTP传输中的状态。 Cookie是存储在浏览器中的一段纯文本信息，建议不要存储敏感信息,如密码。 Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作Baidu的Cookie。 基本特点 Cookie以键值对Key-Value形势进行信息的存储,只能保存字符串对象，不能保存对象类型 Cookie基于域名安全，不同域名的Cookie是不能互相访问的 Cookie保存在客户端,需要客户端浏览器的支持，缺点：浏览器用户可能会禁用Cookie SESSION机制 如果说 Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。 每次客户端发送请求，服务端都检查是否含有sessionId。 如果有，则根据sessionId检索出session并处理；如果没有，则创建一个session，并绑定一个不重复的sessionId。 基本特点 状态信息保存在服务器端。这意味着安全性更高，可以存储敏感、重要的信息，支持更多字节，缺点：Session共享问题 通过类似与Hashtable的数据结构来保存，能支持任何类型的对象(session中可含有多个对象) 保存会话id的技术,依赖于 Cookie。默认情况下在客户端与服务器端之间通过cookie方式传递 SeesionId 总结 两种状态跟踪机制的比较 Cookie Session 存储位置 保持在客户端 保存在服务器端 存储类型 只能保持字符串对象 支持各种类型对象 实现机制 通过过期时间值区分Cookie的类型 ...

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（(RFC 7519). token 被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。 JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该 token 也可直接被用于认证，也可被加密。 Jwt起源 说起 JWT，我们应该来谈一谈基于 token 的认证和传统的 session 认证的区别。 传统的 session 认证 我们知道，http 协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据 http 协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为 cookie, 以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了, 这就是传统的基于 session 认证。 但是这种基于 session 的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于 session 认证应用的问题就会暴露出来. 基于 session 认证所显露的问题 Session: 每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言 session 都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。 扩展性: 用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上, 这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。 CSRF: 因为是基于 cookie 来进行用户识别的, cookie 如果被截获，用户就会很容易受到跨站请求伪造的攻击。 基于 token 的鉴权机制 基于 token 的鉴权机制类似于 http 协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于 token 认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。 流程上是这样的： 用户使用用户名密码来请求服务器 服务器进行验证用户的信息 服务器通过验证发送给用户一个 token 客户端存储 token，并在每次请求时附送上这个 token 值 服务端验证 token 值，并返回数据 这个 token 必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。 那么我们现在回到 JWT 的主题上。 JWT解析 网上大多数介绍JWT的文章实际介绍的都是JWS(JSON Web Signature),也往往导致了人们对于JWT的误解，但是JWT并不等于JWS，JWS只是JWT的一种实现，除了JWS外，JWE(JSON Web Encryption)也是JWT的一种实现。 下面就来详细介绍一下JWT与JWE的两种实现方式： ...