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有效性再决定客户端是否可以获取资源。当然这个架构还是存在一定的性能问题,这个我们后面再优化。