目录
6.3 密码模式(Resource Owner Credentials)
1 什么是OAuth2?
- 是一个代理授权的框架/协议
- 是基于令牌Token的授权(无需用户密码也能拥有访问权限)
- 认证和授权解耦分离
- 主流的标准安全框架,可以支持多种使用场景
- 服务器WebApp
- 浏览器单页SPA
- 无线/原生APP
- 服务器对服务器之间
OAuth使用代理协议的方式解决了密码共享反模式问题。
2 OAuth2核心-令牌Token是什么?
给应用赋予有限的访问权限,让应用有权限去访问用户数据。
举个例子,你把你的保时捷911停到一家酒店,那么你会给酒店服务员保时捷钥匙帮你停车,你给服务员的钥匙,是有限制的,不能行使太远的距离,也不能打开车里的柜子或者是后备箱。
给服务员的钥匙是一个仆从钥匙,相当于令牌Token。
OAuth2的本质就是如何获取token,如何使用token。
3 OAuth2的优势
- 比OAuth1.0更易于实现和理解,也是主流(OAuth1.0有点复杂,而且跟OAuth2几乎是不相干)
- 更安全,避免暴露了用户密码,服务器端更易集中保护
- 广泛传播并被持续采用,成为主流
- token有效期较短并且可以自定义封装token
- 资源服务器和授权服务器解耦
- 集中式授权,简化客户端
- HTTP/JSON友好,易于请求和传递token
- 支持多种架构场景
- 客户可以自定义权限
4 OAuth2的缺点
- 协议框架过于宽泛,导致兼容性和互操作性较差
- 和OAuth1.0不兼容
- OAuth2.0不是一个认证协议,是一个授权框架,本身并不能告诉你任何用户信息。
5 OAuth2的相关术语与其关系
5.1 角色
- 客户应用 - 想要访问用户的受保护资源
- 资源服务器 - 用户的受保护数据保存在此
- 授权服务器 - 在客户应用成功认证并获得授权后,向客户应用颁发访问令牌(Access Token)
- 资源拥有者 - 想要分享某些资源给客户应用
5.2 其他术语
- 客户凭证 - 客户应用的clientId和密码用于认证客户
- 令牌Token - 授权服务器在接收到客户应用请求后,颁发的访问令牌
- 作用域 - 客户应用请求访问令牌时,由资源拥有者额外指定的细分权限
5.3 交互关系
举个例子:
场景:我要玩游戏,游戏可以获取到我的微信好友是否也在玩这个游戏。那么我需要同意授权给游戏获取到我的微信好友。
角色:
- 我本人 - 资源拥有者;
- 游戏 - 客户应用;
- 微信 - 资源服务器;
- 授权服务器 - 管理和颁发Access Token
流程:
- 游戏向授权服务器请求要Access Token,就是要拿到相关的权限去拿到微信好友
- 授权服务器询问我是否同意授权给游戏拿到微信好友信息
- 我选择同意赋予权限
- 授权服务器得知我同意后,生成Access Token并颁发给游戏
- 游戏拿到Access Token后,带上Access Token去请求微信要我的微信好友信息
- 微信校验Access Token,校验通过之后,则把我的微信好友信息返回给游戏。
从上面的流程来看,最关键的一步就是授权和Access Token,那再怎么样授权才能拿到Access Token呢?从这点切入就会了解到OAuth2的四种授权方式。
6 OAuth2的授权方式(Flows)
6.1 授权码模式(Authorization Code)
四种模式中最复杂的一种,也是最安全的,也是目前应用最多的模式。
- (A) 浏览器把客户应用的客户标识等信息发送到授权服务器,并且把重定向的url也一起发送到授权服务器。
- (B) 浏览器得到资源拥有者的同意认证请求后(这个例子我假设资源拥有者是同意授权的),把用户认证信息发送到授权服务器。
- (C) 授权服务器校验用户认证信息,校验正确之后颁发授权码给浏览器,浏览器接受后再返回给客户应用。
- (D) 客户应用拿着授权码以及重定向的url给授权服务器。
- (E) 授权服务器校验授权码等信息无误之后,颁发Access Token和Refresh Token(可选)给客户应用。
特点
- 客户通过前端获取授权码
- 客户通过后端使用授权码去交换Access Token和Refresh Token(可选)
- 最安全的是Access Token不会经过用户代理(浏览器)
此流程图是自己理解过后画的,如要官方流程图,请参考
RFC 6749 - The OAuth 2.0 Authorization Frameworkhttps://datatracker.ietf.org/doc/html/rfc6749#section-4.1
重定向的url是客户应用自己定义的,比如要登录https:web.com ,中途需要认证授权,那么重定向url就是https:web.com。是认证成功之后重定向的url。
6.2 简化模式(Implicit)
比授权码模式简单一点,没有中间的授权码交换,适用于单页应用,没有后台的应用场景。
- (A) 浏览器把客户应用的客户标识等信息发送到授权服务器,并且把重定向的url也一起发送到授权服务器。
- (B) 浏览器得到资源拥有者的同意认证请求后(这个例子我假设资源拥有者是同意授权的),把用户认证信息发送到授权服务器。
- (C) 授权服务器校验认证信息无误后,颁发Access Token和返回重定向url
- (D) 浏览器接受到Access Token后,并返回到客户应用。
特点
- 适用于公开的浏览器单页应用。
- 前端可以直接拿到Access Token,因此也容易受到安全攻击。
- 不支持Refresh Token
起码画的流程图我没有照着官网画,我省略了一个Web托管资源服务器,我觉得如果加上这个对于刚接触的人来说有点难理解。有兴趣的可在官网上查看
6.3 密码模式(Resource Owner Credentials)
- (A) 资源拥有者向客户应用提供用户名密码。
- (B) 客户应用把用户名密码发送到授权服务器。
- (C)授权服务器校验用户信息通过后,直接颁发Access Token和Refresh Token(可选)。
特点
- 使用账号密码登录的应用,比如桌面APP,一般适用于企业内部,是可以高度信任的。
- 使用账号密码作为授权方式从授权服务器上获取Access Token。
- 可以支持Refresh Token但是不推荐使用。
6.4 客户端模式(Client Credentials)
这种也比较简单,甚至都没有资源拥有者的参与,直接由客户应用将客户的认证信息发送到授权服务器,授权服务器校验通过之后返回Access Token给客户应用。这种适用于机器对机器(后端)的场景。
- (A) 客户应用把客户凭证发送到授权服务器
- (B) 授权服务器校验通过之后颁发Access Token
特点
- 只有后端渠道
- 该模式支持共享密码或者证书,因为客户凭证可以使用对称或非对称加密。
7 刷新令牌(Refresh Token)
上文的几种模式中都提到了一个刷新令牌,也就是Refresh Token,那么Refresh Token是什么时候可以用到呢,以及目的是什么呢?
- (A) 一般选择授权码模式
- (B) 校验信息通过之后颁发Access Token和Refresh Token
- (C) 客户应用把拿到的Access Token给到资源服务器
- (D) 资源服务器校验Access Token,验证其有效后把资源返回给客户应用
- (E) 过了一段时间,客户应用又拿着Access Token去请求资源
- (F) 资源服务器校验Access Token发现已经过期,把报错信息返回给客户应用
- (G) 客户应用拿Refresh Token给授权服务器,请求一个新的Access Token
- (H) 授权服务器校验Refresh Token之后,重新生成了新的Access Token和新的Refresh Token(可选)
目的:简化获取Access Token流程,不需要每次都走完成的获取Access Token的流程,快速的获取新的Token。
8 授权流程渠道(Channels)
根据角色之间的交互可以划分渠道。
- 资源拥有者,客户应用,授权服务器参与的称为前端渠道。
- 资源服务器,客户应用,授权服务器参与的称为后端渠道。
9 客户应用类型
我们可以把应用大致分为两类,一个是公开应用,一个是私密应用。
- 公开应用:主要是指单页应用和原生APP。特点是都是在客户端,用户可以直接接触到这些应用。针对这种应用就不能把一些凭证信息(密码之类的)存在这里,不然可能会泄露凭证信息,所以一般只保存用户的标识。
- 私密应用:主要是Web服务器端的应用,还有机器对机器。这种是比较安全和私密的,不仅可以存储用户标识,还可以存储用户凭证,把密码等私密信息存放到后端服务器上。
10 令牌类型
- 授权码(Authorization Code Token):在授权码模型中使用,用于交换获取Access Token和Refresh Token。
- 访问令牌(Access Token):代表资源拥有者直接去访问资源。
- 刷新令牌(Refresh Token):用于去授权服务器获取一个新的Access Token
- Bearer Token:通用型Token,不管是谁拿到该Token都能访问资源。
- PoP Token(Proof of Possession):可以校验客户用户应用是否对Token有明确的拥有权。(因为Bearer Token有时候会存在问题,毕竟谁拿到Token都能用,所以衍生出了PoP Token,可以校验用户是不是有权限使用这个Token)
11 如何选择授权类型
- 如果是机器需要访问资源,可以选择客户端模式;
- 如果是用户需要访问资源
- 如果客户类型是Web服务器端应用,可以选择授权码模式;
- 如果是原生App
- 第一方原生APP(可以理解为同一个公司旗下)
- 选择用户密码模式
- 第三方原生App
- 选择客户端模式
- 如果是单页应用SPA
- 第一方单页应用SPA
- 选择用户密码模式
- 第三方单页应用SPA
- 选择简化模式
12 授权服务器的组成
典型的授权服务的组成,是有四个主要端点组成,也就是四大功能。
- 授权端点:客户端授权时,访问授权端点
- Token端点:通过授权以后,生成Token
- 校验端点:校验Token是否合法
- 吊销端点:对非法客户应用进行吊销
13 对OAuth2的误解
- OAuth没有支持HTTP以外的协议。
- OAuth不是一个认证协议 (管授权不管认证,但是可以扩充支持认证)。
- OAuth没有定义授权代理机制 (授权是应用开发方和资源服务器去管理的)。
- OAuth没有定义Token格式。
- OAuth2没有定义加密方法。
- OAuth2不是单个协议。
- OAuth2只是一个授权框架,仅用于授权代理。
文档链接
阮一峰的网络日志 - 理解OAuth 2.0https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html The OAuth 2.0 Authorization Frameworkhttps://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1