技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统架构 --> OAuth的改变

OAuth的改变

浏览:2307次  出处信息

    去年我写过一篇《OAuth那些事儿》,对OAuth做了一些简单扼要的介绍,今天我打算写一些细节,以阐明OAuth如何从1.0改变成1.0a,继而改变成2.0的。

OAuth1.0

    在OAuth诞生前,Web安全方面的标准协议只有OpenID,不过它关注的是验证,即WHO的问题,而不是授权,即WHAT的问题。好在FlickrAuth和GoogleAuthSub等私有协议在授权方面做了不少有益的尝试,从而为OAuth的诞生奠定了基础。

    OAuth1.0定义了三种角色:User、Service Provider、Consumer。如何理解?假设我们做了一个SNS,它有一个功能,可以让会员把他们在Google上的联系人导入到SNS上,那么此时的User是会员,Service Providere是Google,而Consumer则是SNS。

 +----------+
 |          |
 |   User   |
 |          |
 +----------+
      ^
      |
     (D)
 +----|-----+                                 +---------------+
 |         -+--(C)- Directing --------------->|               |
 |  User-   |                                 |   Service     |
 |  Agent  -+--(D)- User authenticates ------>|   Provider    |
 |          |                                 |               |
 |         -+--(E)- Request Token -----------<|               |
 +-|----|---+       (Authorized)              +---------------+
   |    |                                      ^   v     ^   v
  (C)  (E)                                     |   |     |   |
   |    |                                      |   |     |   |
   ^    v                                      |   |     |   |
 +----------+                                  |   |     |   |
 |          |>-(A)- Obtaining a Request Token -\'   |     |   |
 |          |                                      |     |   |
 |          |<-(B)- Request Token -----------------\'     |   |
 |          |       (Unauthorized)                       |   |
 | Consumer |                                            |   |
 |          |                                            |   |
 |          |>-(F)- Obtaining a Access Token ------------\'   |
 |          |                                                |
 |          |<-(G)- Access Token ----------------------------\'
 +----------+

    Consumer申请Request Token(/oauth/1.0/request_token):

oauth_consumer_key
oauth_signature_method
oauth_signature
oauth_timestamp
oauth_nonce
oauth_version

    Service Provider返回Request Token:

oauth_token
oauth_token_secret

    Consumer重定向User到Service Provider(/oauth/1.0/authorize):

oauth_token
oauth_callback

    Service Provider在用户授权后重定向User到Consumer:

oauth_token

    Consumer申请Access Token(/oauth/1.0/access_token):

oauth_consumer_key
oauth_token
oauth_signature_method
oauth_signature
oauth_timestamp
oauth_nonce
oauth_version

    Service Provider返回Access Token:

oauth_token
oauth_token_secret

    注:整个操作流程中,需要注意涉及两种Token,分别是Request Token和Access Token,其中Request Token又涉及两种状态,分别是未授权和已授权。

OAuth1.0a

    OAuth1.0存在安全漏洞,详细介绍:Explaining the OAuth Session Fixation Attack,还有这篇:How the OAuth Security Battle Was Won, Open Web Style

    简单点来说,这是一种会话固化攻击,和常见的会话劫持攻击不同的是,在会话固化攻击中,攻击者会初始化一个合法的会话,然后诱使用户在这个会话上完成后续操作,从而达到攻击的目的。反映到OAuth1.0上,攻击者会先申请Request Token,然后诱使用户授权这个Request Token,接着针对回调地址的使用,又存在以下几种攻击手段:

  • 如果Service Provider没有限制回调地址(应用设置没有限定根域名一致),那么攻击者可以把oauth_callback设置成成自己的URL,当User完成授权后,通过这个URL自然就能拿到User的Access Token。
  • 如果Consumer不使用回调地址(桌面或手机程序),而是通过User手动拷贝粘贴Request Token完成授权的话,那么就存在一个竞争关系,只要攻击者在User授权后,抢在User前面发起请求,就能拿到User的Access Token。
  •     为了修复安全问题,OAuth1.0a出现了(RFC5849),主要修改了以下细节:

  • Consumer申请Request Token时,必须传递oauth_callback,而Consumer申请Access Token时,不需要传递oauth_callback。通过前置oauth_callback的传递时机,让oauth_callback参与签名,从而避免攻击者假冒oauth_callback。
  • Service Provider获得User授权后重定向User到Consumer时,返回oauth_verifier,它会被用在Consumer申请Access Token的过程中。攻击者无法猜测它的值。
  •     Consumer申请Request Token(/oauth/1.0a/request_token):

    oauth_consumer_key
    oauth_signature_method
    oauth_signature
    oauth_timestamp
    oauth_nonce
    oauth_version
    oauth_callback

        Service Provider返回Request Token:

    oauth_token
    oauth_token_secret
    oauth_callback_confirmed

        Consumer重定向User到Service Provider(/oauth/1.0a/authorize):

    oauth_token
    oauth_callback

        Service Provider在用户授权后重定向User到Consumer:

    oauth_token
    oauth_verifier

        Consumer申请Access Token(/oauth/1.0a/access_token):

    oauth_consumer_key
    oauth_token
    oauth_signature_method
    oauth_signature
    oauth_timestamp
    oauth_nonce
    oauth_version
    oauth_verifier

        Service Provider返回Access Token:

    oauth_token
    oauth_token_secret

        注:Service Provider返回Request Token时,附带返回的oauth_callback_confirmed是为了说明Service Provider是否支持OAuth1.0a版本。

        …

        签名参数中,oauth_timestamp表示客户端发起请求的时间,如未验证会带来安全问题。

        在探讨oauth_timestamp之前,先聊聊oauth_nonce,它是用来防止重放攻击的,Service Provider应该验证唯一性,不过保存所有的oauth_nonce并不现实,所以一般只保存一段时间(比如最近一小时)内的数据。

        如果不验证oauth_timestamp,那么一旦攻击者拦击到某个请求后,只要等到限定时间到了,oauth_nonce再次生效后就可以把请求原样重发,签名自然也能通过,完全是一个合法请求,所以说Service Provider必须验证oauth_nonce和系统时钟的偏差是否在可接受范围内(比如十分钟),如此才能彻底杜绝重放攻击。

        …

        需要单独说一下桌面或手机应用应该如何使用OAuth1.0a。此类应用通常没有服务端,无法设置Web形式的oauth_callback地址,此时应该把它设置成oob(out-of-band),当用户选择授权后,Service Provider在页面上显示PIN码(也就是oauth_verifier),并引导用户把它粘贴到应用里完成授权。

        一个问题是应用如何打开用户授权页面呢?很容易想到的做法是使用内嵌浏览器,说它是个错误的做法或许有点偏激,但它至少是个对用户不友好的做法,因为一旦浏览器内嵌到程序里,那么用户输入的用户名密码就有被监听的可能;对用户友好的做法应该是打开新窗口,弹出系统默认的浏览器,让用户在可信赖的上下文环境中完成授权流程。

        不过这样的方式需要用户在浏览器和应用间手动切换,才能完成授权流程,某种程度上说,影响了用户体验,好在可以通过一些其它的技巧来规避这个问题,其中一个行之有效的办法是Monitor web-browser title-bar,简单点说,操作系统一般提供相应的API可以让应用监听桌面上所有窗口的标题,应用一旦发现某个窗口标题符合预定义格式,就可以认为它是我们要的PIN码,从而无需用户参与主动完成授权流程。Google支持这种方式,并且有资料专门描述了细节:Auto-Detecting Approval(注:墙!)。

    OAuth2.0

        OAuth1.0虽然在安全性上经过修补已经没有问题了,但还存在其它的缺点,其中最主要的莫过于一下两点:其一,签名逻辑过于复杂,对开发者不够友好;其二,授权流程太过单一,除了Web应用以外,对桌面、移动应用来说不够友好。

        为了弥补这些短板,OAuth2.0做了以下改变:

        首先,去掉签名,改用SSL(HTTPS)确保安全性,所有的token不再有对应的secret存在,这也直接导致OAuth2.0不再兼容老版本。

        其次,针对不同的情况使用不同的授权流程,和老版本只有一种授权流程相比,新版本提供了四种授权流程,可依据客观情况选择。

        在详细说明授权流程之前,我们需要先了解一下OAuth2.0中的角色:

        OAuth1.0定义了三种角色:User、Service Provider、Consumer。而OAuth2.0则定义了四种角色:Resource Owner、Resource Server、Client、Authorization Server:

  • Resource Owner:User
  • Resource Server:Service Provider
  • Client:Consumer
  • Authorization Server:Service Provider
  •     也就是说,OAuth2.0把原本OAuth1.0里的Service Provider角色分拆成Resource Server和Authorization Server两个角色,在授权时交互的是Authorization Server,在请求资源时交互的是Resource Server,当然,有时候他们是合二为一的。

        下面我们具体介绍一下OAuth2.0提供的四种授权流程:

        Authorization Code

        可用范围:此类型可用于有服务端的应用,是最贴近老版本的方式。

     +----------+
     | 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)

        Client向Authorization Server发出申请(/oauth/2.0/authorize):

    response_type = code
    client_id
    redirect_uri
    scope
    state

        Authorization Server在Resource Owner授权后给Client返回Authorization Code:

    code
    state

        Client向Authorization Server发出申请(/oauth/2.0/token):

    grant_type = authorization_code
    code
    client_id
    client_secret
    redirect_uri

        Authorization Server在Resource Owner授权后给Client返回Access Token:

    access_token
    token_type
    expires_in
    refresh_token

        说明:基本流程就是拿Authorization Code换Access Token。

        Implicit Grant

        可用范围:此类型可用于没有服务端的应用,比如Javascript应用。

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)--- Redirection URI ----<|               |
     |          |          with Access Token     +---------------+
     |          |            in Fragment
     |          |                                +---------------+
     |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
     |          |          without Fragment      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)------- Script ---------<|               |
     |          |                                +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+

        Client向Authorization Server发出申请(/oauth/2.0/authorize):

    response_type = token
    client_id
    redirect_uri
    scope
    state

        Authorization Server在Resource Owner授权后给Client返回Access Token:

    access_token
    token_type
    expires_in
    scope
    state

        说明:没有服务端的应用,其信息只能保存在客户端,如果使用Authorization Code授权方式的话,无法保证client_secret的安全。BTW:不返回Refresh Token。

        Resource Owner Password Credentials

        可用范围:不管有无服务端,此类型都可用。

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

        Clien向Authorization Server发出申请(/oauth/2.0/token):

    grant_type = password
    username
    password
    scope

        AuthorizationServer给Client返回AccessToken:

    access_token
    token_type
    expires_in
    refresh_token

        说明:因为涉及用户名和密码,所以此授权类型仅适用于可信赖的应用。

        Client Credentials

        可用范围:不管有无服务端,此类型都可用。

     +---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(A)- Client Authentication --->| Authorization |
     | Client  |                                  |     Server    |
     |         |<--(B)---- Access Token ---------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

        Client向Authorization Server发出申请(/oauth/2.0/token):

    grant_type = client_credentials
    client_id
    client_secret
    scope

        Authorization Server给Client返回Access Token:

    access_token
    token_type
    expires_in

        说明:此授权类型仅适用于获取与用户无关的公共信息。BTW:不返回Refresh Token。

        …

        流程中涉及两种Token,分别是Access Token和Refresh Token。通常,Access Token的有效期比较短,而Refresh Token的有效期比较长,如此一来,当Access Token失效的时候,就需要用Refresh Token刷新出有效的Access Token:

     +--------+                                         +---------------+
     |        |--(A)------- Authorization Grant ------->|               |
     |        |                                         |               |
     |        |<-(B)----------- Access Token -----------|               |
     |        |               & Refresh Token           |               |
     |        |                                         |               |
     |        |                            +----------+ |               |
     |        |--(C)---- Access Token ---->|          | |               |
     |        |                            |          | |               |
     |        |<-(D)- Protected Resource --| Resource | | Authorization |
     | Client |                            |  Server  | |     Server    |
     |        |--(E)---- Access Token ---->|          | |               |
     |        |                            |          | |               |
     |        |<-(F)- Invalid Token Error -|          | |               |
     |        |                            +----------+ |               |
     |        |                                         |               |
     |        |--(G)----------- Refresh Token --------->|               |
     |        |                                         |               |
     |        |<-(H)----------- Access Token -----------|               |
     +--------+           & Optional Refresh Token      +---------------+

        Client向Authorization Server发出申请(/oauth/2.0/token):

    grant_type = refresh_token
    refresh_token
    client_id
    client_secret
    scope

        Authorization Server给Client返回Access Token:

    access_token
    expires_in
    refresh_token
    scope

        …

        不过并不是所有人都对OAuth2.0投赞成票,有空可以看看:OAuth 2.0对Web有害吗?

    建议继续学习:

    1. 新浪微博OAuth认证流程分析    (阅读:4060)
    2. 基于PECL OAuth打造微博应用    (阅读:4040)
    3. 深入理解OAuth与豆瓣OAuth test    (阅读:3855)
    4. 在sae中利用SaeFetchurl进行豆瓣的OAuth授权    (阅读:3554)
    5. PHP for Twitter OAuth 教学演示    (阅读:3526)
    6. OAuth那些事儿    (阅读:3195)
    7. OAuth 1.0a与1.0协议的改进…    (阅读:2891)
    8. 新浪微博 Android SDK中OAuth2.0隐式授权部分的一个代码逻辑问题    (阅读:2469)
    9. [演讲稿]OAuth1.0协议    (阅读:2401)
    10. 简述 OAuth 2.0 的运作流程    (阅读:2411)
    QQ技术交流群:445447336,欢迎加入!
    扫一扫订阅我的微信号:IT技术博客大学习
    © 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

    京ICP备15002552号-1