用户登录操作传入用户名和密码，传到后端，后端到DB里查询，如果查到就返回登录成功并把session信息存到内存中并把session的唯一标识（JessionId）返回给我们的浏览器，浏览器就会把我们的JessionId存到cookie里面，当我们下一次请求的时候，一样会被我们的登录拦截器拦截到，然后通过JessionId获取session判断你有没有登录过，如果有就说明你已经登录了，这是我们最传统的基于session的登录校验和登录，参考下图：
传统项目的问题：
1.保存信息到内存，会话保持(session会存储在内存里，如果用户量比较大呢？内存就会被沾满)
2.JessionId存到浏览器cookie里面，如果cookie被拦截就有可能发生CSRF攻击（跨站攻击）
2.单体架构演变分布式架构权限验证session就不能存在一台主机上了，就会存在第三方存储工具（redis/mongodb/db）
这种架构的缺点：
JessionId和用户信息是绑定的，拿到JessionId就能拿到用户信息，一旦JessionId泄露了，别人就有可能CSRF跨域攻击你服务器
3.OAuth2.0框架为我们提供了4种授权方式OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据
这段话的意思就是，OAuth 的核心就是向第三方应用颁发令牌。然后，RFC 6749 接着写道：
（由于互联网有多种场景，）本标准定义了获得令牌的四种授权方式（authorization grant ）。
也就是说，OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。
- 授权码（authorization-code）：指的是第三方应用先申请一个授权码，然后再用该码获取令牌。
- 隐藏式（implicit）：有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。
- 密码式（password）：如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。
- 客户端凭证（client credentials）: 适用于没有前端的命令行应用，即在命令行下请求令牌。
