彻底理解 coookie、session、token，mybatis 的动态 sql 执行原理
大部分你见到过的 API 和 Web 应用都使用 tokens。例如 Facebook, Twitter, Google+, GitHub 等。
五、Token 的起源
在介绍基于 Token 的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。
基于服务器的验证
我们都是知道 HTTP 协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。
在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储 Session 来完成。
下图展示了基于服务器验证的原理
随着 Web，应用程序，已经移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。
基于服务器验证方式暴露的一些问题
Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
可扩展性：在服务端的内存中使用 Seesion 存储登录信息，伴随而来的是可扩展性问题。
CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用 Ajax 抓取另一个域的资源，就可以会出现禁止请求的情况。
CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
六、基于 Token 的验证原理
基于 Token 的身份验证是无状态的，我们不将用户信息存在服务器或 Session 中。
这种概念解决了在服务端存储信息时的许多问题
NoSession 意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于 Token 的身份验证的过程如下:
用户通过用
户名和密码发送请求。
程序验证。
程序返回一个签名的 token 给客户端。
客户端储存 token,并且每次用于每次发送请求。
服务端验证 token 并返回数据。
每一次请求都需要 token。token 应该在 HTTP 的头部发送从而保证了 Http 请求无状态。我们同样通过设置服务器属性 Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。需要主要的是，在 ACAO 头部标明(designating)*时，不得带有像 HTTP 认证，客户端 SSL 证书和 cookies 的证书。
实现思路：
用户登录校验，校验成功后就返回 Token 给客户端。
客户端收到数据后保存在客户端
客户端每次访问 API 是携带 Token 到服务器端。
服务器端采用 filter 过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
当我们在程序中认证了信息并取得 token 之后，我们便能通过这个 Token 做许多的事情。
我们甚至能基于创建一个基于权限的 token 传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的 token）
七、Tokens 的优势
无状态、可扩展
在客户端存储的 Tokens 是无状态的，并且能够被扩展。基于这种无状态和不存储 Session 信息，负载均衡器能够将用户信息从一个服务传到其他服务器上。
如果我们将已验证的用户的信息保存在 Session 中，则每次请求都需要用户向已验证的服务器发送验证信息(称为 Session 亲和性)。用户量大时，可能会造成一些拥堵。
但是不要着急。使用 tokens 之后这些问题都迎刃而解，因为 tokens 自己 hold 住了用户的验证信息。
安全性
请求中发送 token 而不再是发送 cookie 能够防止 CSRF(跨站请求伪造)。即使在客户端使用 cookie 存储 token，cookie 也仅仅是一个存储机制而不是用于认证。不将信息存储在 Session 中，让我们少了对 session 操作。
token 是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到 token 自动失效，token 有撤回的操作，通过 token revocataion 可以使一个特定的 token 或是一组有相同认证的 token 无效。
可扩展性
Tokens 能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook 或是 Twitter)联系起来。当通过服务登录 Twitter(我们将这个过程 Buffer)时，我们可以将这些 Buffer 附到 Twitter 的数据流上(we are allowing Buffer to post to our Twitter stream)。
使用 tokens 时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的 API，得出特殊权限的 tokens。
多平台跨域
我们提前先来谈论一下 CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
只要用户有一个通过了验证的 token，数据和资源就能够在任何域上被请求到。
Access-Control-Allow-Origin: *
基于标准
创建 token 的时候，你可以设定一些选项。我们在后续的文章中会进行更加详尽的描述，但是标准的用法会在 JSON Web Tokens 体现。
最近的程序和文档是供给 JSON Web Tokens 的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。
往期精彩内容：
[Java 知识体系总结（2021 版）](
)
[Java 多线程基础知识总结](
)
[【全栈最全 Java 框架总结】SSH、SSM、Springboot](
)
[超详细的 springBoot 学习笔记](
)
[常见数据结构与算法整理总结](
)
[Java 设计模式：23 种设计模式全面解析](
)
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论