SpringCloud微服务-OAuth2-介绍

OAuth2 是基于开放系统之前的授权访问提出来的

OAuth 历史

OAuth2解决问题域和场景

• 开放系统间授权（社交平台、开放API平台等）
• 现代微服务安全（微服务之间的调用等）
• 企业内部应用认证授权（IAM/SSO等）

OAuth2 的定义和原理

• 用户在请求获取资源时会向授权服务器获取Access Token （吃鸡游戏获取用户微信资源）
• 授权服务器会询问资源拥有者允不允许访问（向微信用户弹窗是否同意授权）
• 资源拥都同意访问
• 授权服务器返回Access Token

什么是OAuth 2.0

• 用于REST/APIs的代理授权框架（delegated authorization framework）
• 基于今牌Token的授权，在无需暴露用户密码的情况下，使应用能获取对用户数据的有限访问权限
• 解耦认证和授权（将认证和授权分离）
• 事实上的标准安全框架，支持多种用例场景（服务端WebApp、浏览器单页SPA、无线/原生App、服务对服务之间）

优势

• OAuth 2.0 比OAuth 1.0 易于实现
• 集中式授权，简化客户端，更安全，客户端不接触用户密码，服务器端更易集中保护
• 短寿命和封装的token
• 资源服务器和授权服务器解耦
• 客户可以具有不同的信任级别
• 考虑多种客户端架构场景

不足

• 协议框架太宽泛，造成各种实现的兼容性和互操作性差
• 和OAuth 1.0不兼容
• 不是一个认证协议
• 本身并不能告诉你任何用户信息
• 不支持HTTP协议以外的协议

OAuth令牌类型

• 授权码 Authorization Code Token(仅用于授权码授权类型，用于交换获取访问令牌和刷新令牌)
• 刷新令牌（用于去授权服务器获取一个新的访问令牌）
• Bearer Token（不管谁拿到Token都可以访问资源，像现钞）
• 访问令牌（用于代码一个用户或服务直接去访问受保护的资源）
• Proof of Possession(PoP) Token（可以交验client是否对Token有明确的拥有权，与Bearer Token的区别是可以交验是否是用户的Token不是谁拿到了都可以使用)

授权码模式

• （A）用户访问客户端，后者将前者导向认证服务器。
• （B）用户选择是否给予客户端授权。
• （C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
• （D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
• （E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

使用场景

• 授权码模式是最安全的流程，因为令牌不会传递经过user-agent，
• 可以使用在假定资源拥有者和客户在不同的设备上。

简化模式

• （A）客户端将用户导向认证服务器。
• （B）用户决定是否给于客户端授权。
• （C）假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。
• （D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
• （E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
• （F）浏览器执行上一步获得的脚本，提取出令牌。
• （G）浏览器将令牌发给客户端。

使用场景

• 适用于公开的浏览器单页应用，
• 简化模式不支持 refresh tokens，
• 假定资源所有者和公开客户应用在同一个设备上

密码模式

• （A）用户向客户端提供用户名和密码。
• （B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
• （C）认证服务器确认无误后，向客户端提供访问令牌。

使用场景

• 使用用户名和密码使用的应用
• 一般不支持refresh tokens
• 假定资源拥有者和公开客户在相同设备上

客户端模式

• （A）客户端向认证服务器进行身份认证，并要求一个访问令牌。
• （B）认证服务器确认无误后，向客户端提供访问令牌。

使用场景

• 适用于服务器间通信场景，机密客户代表它自己或者一个用户
• 客户凭证可以使用对称或者非对称加密，该方法支持共享密码或者证书

OAuth 模式选择图

参考连接：

• http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html