OAuth浅析

Fri 08 February 2019 / In categories Standard

OAuth

本文是对OAuth标准的浅析。 OAuth标准定义了一种Web服务的授权框架,可以让Web服务的用户把自己的权限委托给第三方,让其帮自己执行某些操作。OAuth在RFC6749中定义,跟HTTP、TCP一样,是IETF Standard Track的RFC。

一个引子

我们来讲一个故事帮你理解OAuth到底是什么。

假设你的钱存在国内某个银行,然后你要出国,但是出国不能携带太多现金。于是你想委托一个亲朋好友,当你在国外需要用钱的时候,帮你从国内你自己的银行账户取钱,然后汇给你。最简单的做法,是你将银行卡以及密码都交给你委托的人。可是你有点担心,因为银行有说明,持有银行卡和密码的人对账户的操作,视为账户持有者本人的操作。你的账户里面有非常多钱,你无法完全相信自己所委托的那个人。这完全情有可原,毕竟一个人不可能相信别人超过相信自己。正好该银行提供有一项服务,可以让你签订一个委托取款协议。持有该协议的人,可以去银行从你的账户取协议里面约定的金额。于是你拉上你的亲朋好友,到银行签订了一个委托取款协议,然后你就安心出国了。

必须申明,上面这个例子是臆造的,因为你完全可以通过网上银行来进行跨境汇款操作。

银行提供了这项服务,它就必须保证用户能够安全地使用这项服务。所以银行制定了一些规定

  • 签订委托取款协议的时候,必须本人和受委托人一同前来,并且必须携带各自的身份证件
  • 委托协议的取款金额不能超过100万,并且委托协议的有效期不能超过6个月
  • 受委托人依据委托协议取款的时候,必须携带本人身份证件

可是,安全的对立面是易用性,上面的规定保证了一些安全性,同时也牺牲了一些易用性,比如:

  • 委托取款协议不能在ATM上签订,必须得跑到银行柜台排长长的号办理
  • 如果计划有变,想要的金额或者期限超过了协议的规定,就没有变通的办法了

云相册的例子

跟上面的例子同理,假设你把照片存在一个网盘应用里面(假设这个应用叫做云相册),然后有个第三方应用(假设叫做美颜APP),这个美颜APP可以帮你读取云相册里面的照片,并将你的自拍照片都用美颜滤镜处理一把。你不想把自己云相册的用户名和密码交给美颜APP,于是通过OAuth,你授权美颜APP,让它可以读取你自拍目录下的所有照片,帮你美颜处理。

更具体的过程是这样的,美颜APP给你一个它的Client ID(用来在云相册服务中标识它自己),然后你用自己的用户名密码登录云相册,并把美颜APP的Client ID,告诉云相册你愿意这个Client ID访问你的自拍目录下的照片,于是云相册给你颁布一个Token ID(也称为令牌,通常带有有效期),然后你把Token ID给到美颜APP,这样美颜APP就可以使用自己的Client ID和云相册颁布的Token ID来访问你云相册中自拍目录下的照片了。

所以,云相册颁布的Token ID实际上是一个委托,它包含以下信息:

  • 你在云相册中的ID
  • 美颜APP的Client ID
  • 访问范围,即自拍目录
  • 有效期限

总的来说,OAuth所定义的,就是如何安全的颁布一个Token ID给第三方应用,使这个应用可以访问你愿意它访问的内容。然而,有一点不包含在OAuth的职责里面,就是验证你与第三方APP的信任关系。也就是说,OAuth无法阻止你把令牌颁布给一个恶意的第三方APP。但是你永远拥有撤销第三方APP的访问权限的权利。

上面看似简单的过程中,其实包含大量会带来安全隐患的细节,OAuth需要对这些细节作出规定,从而避免这些安全隐患。

授权(Grant)过程

交互方式

OAuth是给Web服务做安全认证的,所以它是基于HTTPS的协议,也就是用HTTP消息来进行交互,用TLS来执行传输层加密。HTTP消息是Client到Server的非对称消息,所以当Client访问Server的URL的时候,会把请求的参数编码到URL中;然后返回的参数会以JSON各式编码在Server的响应消息中。

相关名词

下面的名词都是抽象的概念:

  • Third-party application:第三方应用,也即是上面例子中的美颜APP。
  • Resource Owner:资源所有者,也就是用户。
  • User Agent:浏览器的泛称。
  • Authorization server:认证服务器,即上面例子中云相册提供委托认证的服务器。
  • Resource server:资源服务器,即上面例子中云相册保存相片的服务器。

四种授权方式

OAuth共有四种授权方式: authorization code、implicit、resource owner password credentials、client credentials。

真正推荐使用的只有authorization code方式,所以下面主要这种授权方式进行讲解。

authorization code授权方式

采用authorization code方式的授权,在颁布Token ID之前,有一个中间步骤,用来获取authorization code。以上面云相册的例子做说明,用户在云相册中授权完美颜APP的时候,会获得一个authorization code。然后用户把authorization code转给美颜APP,接着美颜APP通过authorization code自己向云相册申请获得最终的Token ID。

来自RFC6749中的图:

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

首先解释下上图中的User Agent,也就是浏览器。当美颜APP需要获得用户在云相册的授权的时候,它需要跳转到云相册的授权页面,让用户登录。作为负责任的第三方APP,美颜APP必须启动系统自带的浏览器,而不是自己内嵌的浏览器。因为如果使用自己内嵌的浏览器,第三方APP有可能偷窃到用户的密码。

可能是出于类似的安全原因。苹果在iOS上禁止任何APP内嵌浏览器,而只能调用iOS提供的Safari嵌入版。所以不管iOS上的Chrome、Firefox还是Edge,内嵌的都是Safari。

当用户在系统浏览器中完成授权的时候,必须有办法能够跳转到美颜APP,这是通过一个Redirect URL实现的。对于Web App来说,这个URL可以是http开头的地址;对于本地的APP来说,这个URL可以系统支持的一个Custom URL Schema,比如my-app://

当美颜APP调用系统浏览器来获取授权的时候(也就是上图中的(A)步骤),它必须提供以下信息:

  • Client ID,前面介绍过了,美颜APP在云相册中注册的ID
  • Redirect URL,当授权完成之后,能够通过这个URL返回美颜APP,通常也要求在云相册中注册
  • Scope,授权范围。这是一个可选参数,云相册这个例子里面,这个scope可以用来指定把授权范围限定在自拍相册
  • State,美颜APP生成的nounce,会在授权结束完原样返回给美颜APP。一个负责任的第三方APP应该使用随机的一次性的值作为state,防止自己的身份被盗用。

一个来自OAuth 2 Simplified的例子,征求facebook的授权:

https://facebook.com/dialog/oauth?response_type=code&client_id=CLIENT_ID
  &redirect_uri=REDIRECT_URI&scope=email&state=1234zyx

上面的例子中参数都编码到了URL中了:

  • response_type=code,表示使用authorization code授权方式
  • client_id=CLIENT_ID,CLIENT_ID代表请求的APP的Client ID
  • redirect_uri=REDIRECT_URI,redirect_uri即是redirect_url,假设是fb00000000://authorize
  • scope=email,授权范围是用户的email
  • state=1234zyx,随机的一次性的nounce

在上图流程图中的(B)步骤中用户输入用户名和密码登录;在上面的(C)步骤中,资源服务器返回一个Authorization Code和之前的state参数,然后调用REDIRECT_URI,大概是下面这样子:

fb00000000://authorize?code=AUTHORIZATION_CODE&state=1234zyx

系统能够识别fb00000000://这个Custom URL Scheme,转入第三方APP,并且把Authorization Code和state传给第三方APP。一个负责任的第三方APP必须验证state是自己之前发送的state。然后这个获得的Authorization Code是有时效性的,第三方APP必须尽快去换取最后的Token ID。也就是上面流程图中的(D)步骤和(E)步骤。(D)步骤所需的参数:

  • grant_type=authorization_code,固定格式
  • code=AUTH_CODE_HERE,获取到的Authorization Code
  • redirect_uri=REDIRECT_URI,跟之前发送的redirect_uri一致
  • client_id=CLIENT_ID,跟之前发送Client ID一致

至此,授权流程就结束了。

其他授权方式

  • implicit授权方式,跟authorization code类似,不过省了获取authorization code的步骤,现在差不多完全被authorization code方式替代了。
  • resource owner password credentials授权方式,需要完全信任第三方APP,并提供用户名密码给第三方APP,使用场景较少。
  • client credentials授权方式,其实没有用户什么事。假设美颜APP和云相册是同一家公司的产品,云相册本来就信任美颜APP,所以美颜APP只要给云相册自己的Client ID就可以获得授权了,不需要征得用户的授权。

参考资源

Load Disqus Comments