OAuth2.0系列一：微服务中的安全架构体系

OAuth2.0

首先，需要明确一个概念，OAuth2并不是一个认证协议，它是一个授权框架，仅用于授权代理机制，用来授权第三方应用，获取用户数据。那么OAuth2到底是什么？下面通过一个例子了解一下。

假设我在一个云存储服务上有一些文件，但是这个云存储服务没有打印功能，我想通过一个云打印服务来打印云存储服务上的文件，那么通过什么办法可以实现我这个需求呢？

方式一：用户名密码复制

通过这种方式，会把用户名和密码泄露给云打印这些第三方应用，这对于资源拥有者来说是不安全的。

方式二：特殊令牌

云存储服务颁发给云打印服务一个特殊的令牌，云打印服务通过这个服务只能访问资源拥有者授权了的资源。

明显可见，第二种方式比第一种方式要安全的多，也是当前比较流行的授权模式。

OAuth2.0的定义

通过上面的例子，总结一下OAuth2的定义。OAuth2就是一种基于Access Token的授权机制，在无需暴露密码的情况下，数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统通过产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

OAuth2.0中的角色

资源拥有者：资源的拥有人，想要分享某些资源给第三方应用。

客户应用：第三方应用，通常是一个Web或者无线应用，它需要访问用户的受保护资源。

授权服务器：在客户应用成功认证并获得授权之后，向客户应用颁发访问令牌Access Token。

资源服务器：是一个web站点或者web serviceAPI，用户的受保护数据保存于此。

OAuth2.0中的术语

客户凭证：客户的clientId 和密码用于认证客户。

令牌：授权服务器在接收到客户请求后，颁发的访问令牌。

作用域(Scopes)：客户请求访问令牌时，由资源拥有者额外指定的细分权限。

OAuth2.0解决的问题和场景

• 社交联合登录、开放API平台，如常见的qq登录、新浪微博登录、微信登录等。
• 现代微服务安全（服务器端webapp、单页应用（HTML5、JS）、无线/原生APP、服务器和API调用）
• 企业内部应用认证授权（IAM/SSO）

OAuth2.0的优势

• OAuth2比OAuth1易于实现
• 更安全，客户端不接触用户密码，服务器端更易集中保护
• 广泛传播并被持续采用
• 短寿命和封装的token
• 资源服务器和授权服务器解耦
• 集中式授权，简化客户端
• HTTP/JSON友好，易于请求和传递token
• 考虑多种客户端架构场景，支持多种用例场景：服务器端webapp、单页应用（HTML5、JS）、无线/原生APP、服务器和API调用
• 客户可以有不同的信任级别

OAuth2.0的不足

• 协议框架太宽泛，造成各种实现的兼容性较差
• 和OAuth1不兼容
• OAuth2不是一个认证协议，通过OAuth2本身不能获取用户的任何信息，但是我们可以扩展支持

OAuth2.0的令牌类型

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

令牌和密码的区别是令牌可能只有密码的一部分权限，用户可以随时撤销令牌，而且令牌是短期的，避免令牌泄露的安全问题。

现代微服务安全架构设计方案

图片截自《微服务架构实战160讲》——杨波

现代微服务系统中的客户端可能不仅仅是网站website，有可能是移动端APP、服务器端webapp等，需要一个统一的授权中心(AuthServer)进行授权管理。客户端先通过授权中心获取Access Token，然后每次去资源服务器获取资源时带着token，各个服务先判断token有效性再决定客户端是否可以获取资源。当然这个架构还是存在一定的性能问题，这个我们后面再优化。

下篇文章将会介绍OAuth2.0的四种授权模式。

参考文章和课程：

OAuth2.0标准 RFC6749

OAuth 2.0 的一个简单解释

登录工程：传统 Web 应用中的身份验证技术

《微服务架构实战160讲》——杨波