无论哪种身份认证办法，只要用户通过了认证，这之后的访问过程中，只要我们没有主动登出，用户身份也没有过期，SSO（单点登录）也没有踢出你的身份，那始终是可以正常访问资源的。在普通用户利用层面上是无感知的，他知道当前用的身份便是我自己，那么对付做事器是怎么判断当前访问资源的用户是谁呢？
做事端判断身份cookie、session做事端在用户认证通过后，在 response 的 cookie 中加一个 JSESSIONID（随机标识）返回给前端，同时在做事端 session 中存储这个 id 对应的用户工具，这样在之后的要求中我们都能通过前端传来的 JSESSIONID 找到 session 中对应的用户数据，也就能知道是哪个用户访问资源了。
当然了，你假如头铁，完备也可以把用户工具序列化后放在 cookie 中回传给前端，后端在每次要求中解析这个 cookie，拿到用户数据，但估计你离被辞退也不远了。
由于 session 默认都是在本机存储的，这对付集群做事就麻烦了，获取不到对应的用户工具，后来就演化出在数据库、redis 等缓存中间件中存储 session 数据。数据库存 session 性能比较差，现在基本都是缓存中间件来存储。
token（OAuth2.0）一个字符串，比如 cdf62cb2-b6de-460c-8856-d9339d923012，可以根据它通过指定的查询办法，获取用户信息。比如如果配置了通过 redis 获取，则这个 token 便是 key，获取的 value 便是用户信息。
实在这种办法跟 cookie 非常像，为什么又单独搞出一个 OAuth2.0 模式呢？由于 cookie 不能跨终端，某些用户设置浏览器不许可访问 cookie 也会失落效。而 token 就不一样了，只是一个字符串，完备可以跨终端，而且保存在 js 中也不须要 cookie 支持。
JWT（JSON Web Tokens）与 token 模式相同，只不过这里存储的不是 token 那么大略的字符串，而是一个包含有效数据的加密字符串，比如：BearereyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsImNyZWF0ZWQiOjE1Nzg4OTgxNzIzNjQsImV4cCI6MTU3OTUwMjk3Mn0._PxIFHqBBx1RN1C3plyT8_9TepCs35lSU2P9n1jZ1Esvmi5yK2t6h4pl_QsRIBjFOam2TFxwln68lF2BEAcu5Q，精确解密后可以直接拿到用户信息，比如用户 id、用户名等等，就看你敢往里面塞多少内容了。好处是不须要再次去别的地方查用户数据，坏处么，塞得东西越多，每次传输的内容就越大，而且是存储在客户真个，敏感信息不应该放在里面。
JWT 的构成第一部分我们称它为头部（header)，第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，第三部分是签证（signature)。第三部分是一个签证信息，这个签证信息由三部分组成：
header (base64 后的)payload (base64 后的)secretOAuth2.0 先容OAuth2.0 的大略交互流程如下图：
这里简化了用户授权过程中后真个交互，由于 OAuth2.0 的授权模式有四种：
密码模式（resource owner password credentials）这种模式是最不推举的，由于客户端会知道用户密码支持 refresh token授权码模式（authorization code）这种模式算是正宗的 oauth2 的授权模式设计了 auth code，通过这个 code 再获取 token支持 refresh token简化模式（implicit）如图这种模式比授权码模式少了 code 环节，回调 url 直接携带 token不支持 refresh token客户端模式（client credentials）这种模式直接根据 client 的 id 和密钥即可获取 token，无需用户参与这种模式比较得当消费 api 的后端做事，比如拉取一组用户信息等不支持 refresh tokenOAuth2.0直不雅观配置去这里看看
OAuth2.0要求验证过程看这里
