OAuth1.0 简介及安全分析

1.   概述

OAuth 是一个开放授权协议，允许第三方应用访问服务提供方中注册的终端用户的某些资源，且不会把帐号和密码提供给第三方。

OAuth 允许通过服务提供商授予的一个临时令牌而不是用户名密码来获取用户的资源，这些资源可以是受限的，令牌的时间段也可以是受限的。

1.1     OAuth 的参与者

1.       终端用户

存放在服务提供方的受保护的资源的拥有者

2.       第三方应用

通常是网站，如提供照片打印服务的网站

3.       服务提供者

拥有用户存储的受保护的资源，如照片，视频，联系人列表等

1.2     三个 Endpoints

1.       Request Token

用于获取访问令牌

2.       User Authorization

重定向的 URI ，让用户授权

3.       Access Token Request

获取访问令牌

1.3     OAuth 流程

雅虎的图画的比较好，就用它了

图表 1 OAuth 流程图

1. 第一步：申请成为yahoo的客户端应用（Application），yahoo颁发consumer_key和shared_secret，以后客户端应用就通过这个confidentials标示自己并和yahoo交互；

2. 第二步：获取oauth_token，客户端应用将请求参数编码后用指定的oauth_signature_method及shared_secret&签名，yahoo获得请求参数用同样的方法对参数签名，然后和请求参数里的oauth_signature对比，如果相同则客户端认证通过，授予临时的oauth_token和oauth_secret；

3. 第三步：客户端应用重定向用户浏览器到yahoo的登录页面，请求参数带oauth_token，yahoo验证该token是否是自己颁发，如果是则可能让用户登录（可能用户已经登录），并明确告知用户客户端应用要获取用户什么个人数据，用户同意后，yahoo重定向用户浏览器到客户端应用的oauth_callback页面，并带参数oauth_verifier；

4. 第四步：客户端应用请求一个长期有效的oauth_token，同样对请求参数编码并用shared_secret&oauth_token_secret签名，注意参数里要包含上一步获取的oauth_verifier，yahoo验证通过后返回长期有效的oauth_token和oauth_secret，以及过期时间：oauth_expire_in；接着客户端应用用这个token获取用户个人数据，直到token过期；

5. 第五步：客户端应用用之前的oauth_access_token获取新的token;

 

注意：这里的oauth_timestamp和oauth_nonce是为防止重放攻击而设置的。具体的来讲：请求者不能在一段时间（服务器允许的客户端和服务端的时间差）内发送同样的请求两次或以上，如果在这个时间段之后再次发生这个请求，则会因为超出服务端允许的时间差而被拒绝。

 

1.4 术语解释

1.       Consumer Key

第三方应用在服务提供方注册的标示（类似用户名）

2.       Shared secret

服务提供方提供的验证第三方应用的密钥（类似密码）

3.       Reqeust Token

请求令牌，用于标示这次请求

4.       Access Token

访问令牌，表示第三方应用已获得用户授权

2       安全

2.1     安全分析

协议中涉及的三方

图表 2 协议中的三方

 

为描述方便，服务提供方简称 SP 。

1.       SP 和客户端之间的交换密钥的通信是通过 SSL 加密隧道（ HTTPS ）的，因此排除第三方攻击者窃取密钥数据的可能。

2.       获取 Access Token 之后，通过 HTTP 获取用户资源，需要客户端的密钥和 Access Secret 签名数据，第三方攻击者很难猜测这两个密钥，除非客户端泄露。

3.       由于 SP 对客户端是不够信任的，因此我们要防止客户端用各种方式绕过用户授权窃取用户数据。如通过已授权的用户 A 去获取用户 B 的信息，即通过获得授权用户 A 的 Access Token 和 Access Secret 猜测分析用户 B 的 Access Token 和 Access Secret 。

2.2     Core1.0 的安全漏洞

2009 年 4 月 23 日， OAuth 宣告了一个 1.0 协议的安全漏洞。该漏洞影响了 OAuth 1.0 核心规范第 6 节的 OAuth 的认证流程（也称作 3 阶段 OAuth ）， OAuth Core 协议 1.0a 版本解决了这一问题。

问题描述

1. 攻击者到一个合法的 Consumer 站点获得一个 request token
2. 利用 trap site 让受害者授权这个 request token
3. 之后针对 callback 的不同，有几种不同的处理方法：

a)       如果 Provider 站点对第二步（请求用户授权 , 图中第 3 步）中的 callback 没有限制，那么攻击者可以利用 trap site 将 callback 设为自己的站点，然后通过这个 callback 判断受害者何时完成授权。等到受害者授权后，攻击者访问合法的 callback 来获得受害者的 access token

b)       其他的情况下（使用预定义的静态 callback 、没有 callback 由用户手工完成授权），那么攻击者和受害者之间进行竞争，当攻击者恰好在受害者授权和访问 callback 的间隙访问合法的 callback ，那么攻击者就获得了受害者的 access token

解决方案

1.0a 的版本提供了以下改进：

1.       oauth_callback 在第一步即获取 Request Token 时（ Get Request Token ，图中第二步）就必须提供，如果不需要重定向，则其值必须为 oob （ out_of_band configuration ），服务提供方此时返回参数 oauth_callback_confirmed ，且值为 true 。在第二步即验证阶段（图中第三步）不接受该参数。

2.       验证完成后会返回验证码（ oauth_verifier ）为的是在没有 callback 的时候，服务提供方显示给用户，然后用户可以在第三方应用的设备上输入，标示自己已经授权（和未授权的用户分开），然后第三方应用必须加上该验证码去获取 Access Token

然而实际上 OAuth1.0 最终版（已经成为 RFC5849 标准）已经没有这个安全的漏洞了。

2.3     协议提及的安全考量

OAuth 协议（ RFC5849 标准）文档上提出了以下安全考量，对应 http://tools.ietf.org/html/rfc5849#section-4

1.       似乎说 RSA_SHA1 更安全

2.       建议用 SSL 或者 TLS 保证请求的安全

3.       建议用 SSL 或者 TLS 保证确认服务提供者的身份

4.       客户端 proxy 或者 cache 的安全

5.       服务端密钥的安全存储

6.       客户端密钥的安全存储

7.       警告用户，防止用户的疏忽

8.       由于第三方应用的不可信任（可能希望获取更多的用户资源），需对授权的资源严格的分类，并告知明确用户可能存在的风险

9.       密钥的安全性，最好是真正的随机数

10.   DOS/DDOS 攻击

11.   SHA-1 自身的漏洞

12.   签名只是保证了 base_string 的完整

13.   CSRF （ Cross Site Request Forgery ）

14.   Clickjacking

15.   客户端密钥的安全

 

上面的各条中黑体的条款，我们需要注意，其他是客户端或者用户需要防范的，我们服务提供方需要给用户足够的信息去确认授权的风险。

2.3     总结

其实协议 1.0 定稿后，已经广泛使用，其本身不会有什么安全漏洞，但协议的实现可能存在漏洞，这是我们需要花精力去测试的。