【转自】https://stayhungrystayfoolish.github.io/Token/
基本概念了解
状态
请求的状态是 浏览器（Client） 与 服务端（Server） 交互过程中，保存下来的相关信息，客户端的保存在 page/request/session/application 或者全局作用域中，而 Server 的一般存在 Session 中。
有状态 API
服务端（Server）保存了 浏览器（Client） 的请求状态，Server 通过 Client 传递的 sessionID 在其 Session 作用域内找到之前交互的信息并应答。
无状态 API
无状态是 RESTFul 架构设计的一个非常主要的原则。
每一个请求都是独立的，它要求由 浏览器 保存所有需要的认证信息，每次发请求都要带上自己的状态，以 URL 的形式提交包含了 Cookies 等状态的数据。
关键词解读
Token
在计算机领域，Token 通常指的是一种令牌，用于身份安全认证。
最简单的 Token 组成：uid（用户唯一的身份标识）、time（当前时间的时间戳）、sign（签名，由 Token 的前几位 + 盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器）。
Cookie
Cookie 通过在浏览器记录信息确定用户身份，存储在浏览器
一种在浏览器记录用户信息的技术，由服务器发送给浏览器并保存相关信息（超过4kb 不可读）。因为 Http 协议是无状态的，为了解决这个问题而产生了 Cookie 。
Cookie的组成有：名称（Key）、值（Value）、有效域（Domain）、路径（域的路径，一般设置为全局:”\”）、失效时间（Expires）、安全标志（指定后，cookie只有在使用SSL连接时才发送到服务器（Https））。
Session
Session 通过在服务器记录信息确定用户身份，存储在文件、数据库或内存之中
一种服务器与浏览器的会话机制，浏览器发送一个请求到服务器，服务器记录当前用户信息，产生一个 session id，用来在服务器端共享数据。
Session 的生命周期一般自己设置，当超过设置的有效时间，该会话状态关闭。
传统身份认证与基于 Token 的认证
传统身份认证
HTTP Basic Auth
HTTP Basic Auth 是每次请求API时都提供用户的 username 和 password ，简言之，Basic Auth 是最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方浏览器的风险，在生产环境下被使用的越来越少。因此，不推荐采用 HTTP Basic Auth。
Cookie Auth
Cookie Auth 机制 是当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID 号发送给浏览器，浏览器收到将 ID 存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个 Cookie 里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给浏览器
Cookie 与 Session 合作：
因为如果我们把所有信息全都存在 Cookie，很容易被用户在浏览器看到或者在 JS 脚本修改，Cookie 存储数据大小也受限，太大传输效率就低了，所以我们把一些敏感或者量大的数据存在 Session里。
-
将两者信息进行匹配验证，即浏览器（Cookie）和服务器端（Session）之间的验证。
为什么需要这两者的合作？ HTTP是一种无状态无连接的协议，即请求是不知道是谁请求，需要在这两者之间做一层身份的识别。 就如原本是去商场用现金交易，付款后就不知道用户是谁了， 现在变成线上支付，加了一层身份识别，我们就可以对用户进行追踪了。
认证过程
浏览器使用户用户名和密码访问，通过了验证
服务端将浏览器信息进行处理加密（签名，专业术语叫信息摘要算法）
把记录这些信息的 ID 发送给浏览器
浏览器收到 ID 后存储在 Cookie 中
下次浏览器重新访问服务端时，带上 Cookie 信息
服务端验证 Cookie 里面的信息，如果能找到对应的记录，则用户通过了验证
Cookie Auth 认证暴露的问题
-
扩展性
用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话， 这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源， 这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。 -
CSRF
因为是基于 Cookie 来进行用户识别的, Cookie 如果被截获，用户就会很容易受到跨站请求伪造的攻击。 -
CORS
因为浏览器引入了`同源策略`（同域, 同协议, 同端口）， 但在实际需求中，又不得做一些跨域的请求。跨域又会引起上述的 CSRF 。 提示：CORS 并不能防止 CSRF 攻击。CORS 机制是为了解决脚本跨域请求的问题，无法防止 CSRF。 CSRF 攻击的发起有多种方式，如html资源标签、form表单提交、JS代码发起请求
基于 Token 认证
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。
认证过程：
浏览器使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给浏览器
浏览器收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
浏览器每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证浏览器请求里面带着的 Token，如果验证成功，就向浏览器返回请求的数据
Token 优势
-
无状态，可扩展性
如前所述，服务器端不存储会话，可扩展性强，如果有多台服务器，会话信息存储地方不只一个的话， 就需要某种同步机制，或者想办法知道用户和 Session 存储地的对应关系。 -
支持跨域
Cookie是不允许垮域访问的，浏览器有跨域问题，如果有好几个不同的网站的话，Cookie Auth 需要在 login 的时候给 所有的 Domain 写上 Cookie，通常做法应该是有个 SSO Endpoint，登陆成功后跳转到专门的页面， 页面上用iframe之类的分别调用各个 Domain 的 Cookie Endpoint。 这一点对 Token 机制是不存在的，前提是传输的用户认证信息通过HTTP头传输。 -
解耦
无需使用特定的身份验证方案，只要拥有生成 Token 所需的验证信息， 在何处都可以调用相应接口生成 Token，无需繁琐的耦合的验证操作，是一次生成，永久使用。 -
性能
Token 不用查 DB ，然后用户角色的划分，也可以通过 Token 中的数据进行查看。 -
支持非浏览器环境，更适应移动应用
原生平台（iOS, Android 等），Cookie 是不被支持的（你需要通过Cookie容器进行处理）， 采用 Token 认证机制比较合适。 -
标准化
你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和 多家公司的支持（如：Firebase,Google, Microsoft）.
参考文献：
http://tech.colla.me/zh/show/token_session_cookie
https://b1ngz.github.io/csrf-and-cors/
https://my.oschina.net/hosee/blog/903665
- **版权声明： **本博客所有文章除特别声明外，均采用 CC BY 4.0 CN协议 许可协议。转载请注明出处！
