目录
需求驱动
最近项目上要做一个登录认证模块，于我而言，还停留在session会话在记忆里。
比如，下面最简单的一个登录流程
用户第一次访问业务系统时，
- 后端filter检验用户未登录，跳转登录页面
- 用户输入账密，提交到后端
- 后端检验账密
- 检验成功，将用户信息放入session
- 检验失败，返回页面错误提示信息
用户再次访问业务系统时，业务系统filter拦截到用户请求，从session中获取用户成功，则用户已登录，不用再重新登录，直到session会话失效(一般会对session会话设置过期时间，由servlet服务器管理)
传统session会话的局限性
分布式会话管理
现在的系统，尤其是互联网系统，基本都不再是传统的单机部署了。在集群的场景下，对于session会话，一种在前应用服务前面加一个反向代理，比如Nginx或者F5这种设备，用做会话保持，否则就算有session会话，也会导致用户有可能重复登录
- 系统集群部署，有N个节点，假设前面的登录过程发生在server1上面，那么session会话也存在于这台服务器上
- 如果同一个用户的后续请求，被打到了server2，serverN，等任一一台上面，由于没有该用户的session信息，都会导致判断用户未登录而导致让用户重复登录
当然这种情况也有对应的解决方案，比如
- 通过负载均衡器，做会话保持
- session会话集中式存储
- 服务器节点间做session会话同步
不过，这些并不是今天要讨论的重点，后续有机会可以单独的研究一下
移动端的冲击
不知道你有没有发现，很多时候登录某APP时，我们并不需输入账密甚至注册新账号了，可以选择用微信或者支付宝做授权，就可以进行登录了（当然还有其它的一些APP，比如微博，京东等，前提是你安装了它）。
这种通过其它应用授权登录的方式，极大的简化了操作，也提升了用户体验。那么就会问，这种登录方式到底是一种什么机制呢，它与传统的session会话有什么不同？
其它这背后就是oauth2的授权机制。
而这次项目的登录认证，就是采用的oauth2的授权码模式！
所以有的时候，学习一个新技术或者框架，工作中的需求也是很好的机会！
什么是Oauth2
看一下百科的定义，OAuth2.0
OAuth2.0是OAuth协议的延续版本，但不向前兼容OAuth 1.0(即完全废止了OAuth1.0)。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749 [1] 。
其实一眼看过去，也不是很明白什么oauth2，它到底能做什么
- oauth2也是一种授权协议，是oauth1的升级版本
- oauth2即可以用做认证，也可以用做授权
- oauth2的认证场景有多种：PC应用端，APP移动端，甚至是硬件设备上
我个人理解，其实oauth2就是一种授权协议。怎么理解这个地方的授权呢？
还是以刚才的登录某APP为例，在登录时，可以不用输入账密，直接通过微信进行授权登录。
看一下网站应用微信登录开发指南
上面是微信登录的时序流程：
- 首先登录用户必须是微信用户，才能用微信进行授权登录
- 第三方应用在网站或者APP上面，集成微信登录的入口
- 用户点击微信登录，三方应用向微信发起授权登录请求
- 微信开放平台收到请求后，会引导用户到微信授权界面，让用户确认是否授权，并勾选授权的用户信息，比如昵称，性别等属性
- 用户授权之后，微信开放平台会生成code，并重定向到业务系统，将code返回给业务系统
- 业务系统通过code，发起请求到微信获取用户登录的token
- 到此授权登录请求完成
到这里，有没有一种很熟悉的感觉，至少或多或少都碰到过这种三方授权登录吧。
通过上面的流程，基本感知了oauth2的应用场景。
其实这种流程在oauth2中有专门的模式名称：叫做授权码模式，也是最复杂并且是最安全的模式。
那么oauth2到底有几种模式呢？每种模式的应用场景是什么？
Oauth2的模式
oauth2现在一般有4种模式
授权码模式（authorization code）
授权码方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。
隐藏式（implicit）
有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。
密码式（password）
如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。
客户端凭证（client credentials）
最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。
如果有兴趣，可以看一下此篇文章的介绍，有个初步的概念
Oauth2用作认证
oauth2只能做授权吗？能否用在传统的用户认证上面呢？
其实有一种授权认证协议叫作OIDC，就是基于oauth2做的用户认证的。
它是结合了oauth2的授权+jwt令牌的认证的一种比较复杂且安全的认证协议，阿里云的idaas身份管理项目就支持这种认证方式
里面有各种协议的时序图，这里就不引用了，有兴趣可以自行查看一下
oauth2的安全保护
oauth2与其它认证方式相比，它的安全性如何保证的？
由于安全是一个很大话题，后面找个章节单独研究一下，这里就先不展开了
一下节预告
最后，可能已经对oauth2有个初步的概念，或者叫混了个脸熟。
在下一节，先会详细探究一下授权码模式！
4980
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
