OAuth2的原理和应用

定义

OAuth是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用【1】。

场景：

OAuth主要用于第三方应用访问用户在某一网站上存储的隐秘资源。

实例【2】

有一个"云冲印"的网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取自己储存在Google上的照片。

问题是只有得到用户的授权，Google才会同意"云冲印"读取这些照片。那么，"云冲印"怎样获得用户的授权呢？

传统方法是，用户将自己的Google用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。

• "云冲印"为了后续的服务，会保存用户的密码，这样很不安全。
• Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。
• "云冲印"拥有了获取用户储存在Google所有资料的权力，用户没法限制"云冲印"获得授权的范围和有效期。
• 用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。
• 只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的。

参与角色：

• Third-party application：第三方应用程序，本文中又称客户端（client），即上一节例子中的"云冲印"。
• HTTP service：HTTP服务提供商，本文中简称服务提供商，即上一节例子中的Google。
• Resource Owner：资源所有者，本文中又称用户（user）。
• User Agent：用户代理，本文中就是指浏览器。
• Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
• Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

关键技术：

OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站）在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

一个令牌包含了login session的安全证书，存储了用户本身的信息，用户的组信息，用户的权限信息，在某些时候，还包括了特定应用的信息【3】。

应用

OAuth在客户端与服务提供商之间，设置了一个授权层（authorization layer）。客户端不能直接登录服务提供商，只能登录授权层，以此将用户与客户端区分开来。客户端登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。
客户端登录授权层以后，服务提供商根据令牌的权限范围和有效期，向客户端开放用户储存的资料。

客户端获取授权有四种模式，授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。这里一次为例，简要介绍OAuth的工作原理。

oauth.png

它的步骤如下：

（A）用户访问客户端，后者将前者导向认证服务器。
（B）用户选择是否给予客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的重定向URI（redirection URI），同时附上一个授权码。
（D）客户端收到授权码，附上早先的重定向URI，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

下面是上面这些步骤所需要的参数。

A步骤中，客户端申请认证的URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为"code"
• client_id：表示客户端的ID，必选项
• redirect_uri：表示重定向URI，可选项
• scope：表示申请的权限范围，可选项
• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。
  下面是一个例子。

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

C步骤中，服务器回应客户端的URI，包含以下参数：

• code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

下面是一个例子。

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：

• grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。
• code：表示上一步获得的授权码，必选项。
• redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
• client_id：表示客户端ID，必选项。
  下面是一个例子。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

E步骤中，认证服务器发送的HTTP回复，包含以下参数：

• access_token：表示访问令牌，必选项。
• token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
  下面是一个例子。

         HTTP/1.1 200 OK
         Content-Type: application/json;charset=UTF-8
         Cache-Control: no-store
         Pragma: no-cache
    
         {
           "access_token":"2YotnFZFEjr1zCsicMWpAA",
           "token_type":"example",
           "expires_in":3600,
           "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
           "example_parameter":"example_value"
         }

从上面代码可以看到，相关参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存。

Token 传递方式

在第三方Client拿到access_token后，如何发送给Resouce Server这个问题并没有在RFC6729种定义，而是作为一个单独的RFC6750来独立定义了。这里做以下简单的介绍，主要有三种方式如下【8】：

• URI Query Parameter.

GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1

Host: server.example.com

Client需要设置以下Request Header的Cache-Control:no-store，用来阻止access_token不会被Web中间件给log下来，属于安全防护方面的一个考虑。

• Authorization Request Header Field.

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

• Form-Encoded Body Parameter.
  使用Request Body这种方式，有一个额外的要求，就是Request Header的"Content-Type"必须是固定的“application/x-www-form-urlencoded”，此外还有一个限制就是不可以使用GET访问，这个好理解，毕竟GET请求是不能携带Request Body的。

POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=mF_9.B5f-4.1JqM

问题：Cover Redirect

隐蔽重定向【4】，是关于单点登录的安全漏洞。由新加坡南洋理工大学物理和数学科学学院博士生王晶发现并命名。
隐蔽重定向的一个重要应用是进行钓鱼时攻击，别的网站钓鱼是用假的网站，而隐蔽重定向是用真的知名网站进行钓鱼，这是一种完美的钓鱼方式。

攻击者可以将direct_uri设置为自己开发的应用（即第三方应用），并使其指向正规大站（例如facebook或者新浪微博之类）的应用授权服务器，当用户点击一个钓鱼链接时，会跳出一个正规大站的应用授权窗口，要求你为一个新应用授权访问，如果用户对其授权，之后，攻击者的应用将可以窃取用户的个人信息如邮件地址、联系人等信息，并发回给攻击者【5】。

解决方案：

有多种漏洞防范的方式【6】，比较常用的是要求第三方应用的开发者为应用注册redirect url，也就是建立白名单【7】。

授权 vs 认证 （OIDC）

OAuth2是一个授权协议（授权层），无法提供完善的身份认证功能，OIDC在OAuth2之上构建了一个身份层，是一个基于OAuth2协议的身份认证标准协议。OIDC使用OAuth2的授权服务器来为第三方客户端提供用户的身份认证，并把对应的身份认证信息传给客户端。

【1】OAuth
【2】理解OAuth 2.0
【3】Access_token
【4】隐蔽重定向
【5】互联网安全地震第三波：OAuth/OpenID认证爆漏洞
【6】漏洞防范
【7】redirect-uri-registration
【8】# [认证 & 授权] 1. OAuth2授权