OAuth - 四种方式

OAuth 2.0 的标准是 RFC 6749 文件。该文件先解释了 OAuth 是什么。

OAuth 引入了一个受权层，用来分离两种不一样的角色：客户端和资源全部者。......资源全部者赞成之后，资源服务器能够向客户端颁发令牌。
客户端经过令牌，去请求数据。

这段话的意思就是，OAuth 的核心就是向第三方应用颁发令牌。而后，RFC 6749 接着写道：

因为互联网有多种场景，）本标准定义了得到令牌的四种受权方式（authorization grant ）。

也就是说，OAuth 2.0 规定了四种得到令牌的流程。你能够选择最适合本身的那一种，向第三方应用颁发令牌。下面就是这四种受权方式。

• 受权码（authorization-code）
• 隐藏式（implicit）
• 密码式（password）：
• 客户端凭证（client credentials）

注意，无论哪种受权方式，第三方应用申请令牌以前，都必须先到系统备案，说明本身的身份，而后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。这是为了防止令牌被滥用，没有备案过的第三方应用，是不会拿到令牌的。

第一种受权方式：受权码

受权码（authorization code）方式，指的是第三方应用先申请一个受权码，而后再用该码获取令牌。

这种方式是最经常使用的流程，安全性也最高，它适用于那些有后端的 Web 应用。受权码经过前端传送，令牌则是储存在后端，并且全部与资源服务器的通讯都在后端完成。这样的先后端分离，能够避免令牌泄漏。

第一步，A 网站提供一个连接，用户点击后就会跳转到 B 网站，受权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意连接。

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上面 URL 中，response_type参数表示要求返回受权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的受权范围（这里是只读）。

第二步，用户跳转后，B 网站会要求用户登陆，而后询问是否赞成给予 A 网站受权。用户表示赞成，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个受权码，就像下面这样。

https://a.com/callback?code=AUTHORIZATION_CODE

上面 URL 中，code参数就是受权码。

第三步，A 网站拿到受权码之后，就能够在后端，向 B 网站请求令牌。

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，所以只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的受权方式是受权码，code参数是上一步拿到的受权码，redirect_uri参数是令牌颁发后的回调网址。

第四步，B 网站收到请求之后，就会颁发令牌。具体作法是向redirect_uri指定的网址，发送一段 JSON 数据。

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。

第二种方式：隐藏式

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，容许直接向前端颁发令牌。这种方式没有受权码这个中间步骤，因此称为（受权码）"隐藏式"（implicit）。

第一步，A 网站提供一个连接，要求用户跳转到 B 网站，受权用户数据给 A 网站使用。

https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上面 URL 中，response_type参数为token，表示要求直接返回令牌。

第二步，用户跳转到 B 网站，登陆后赞成给予 A 网站受权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，而且把令牌做为 URL 参数，传给 A 网站。

https://a.com/callback#token=ACCESS_TOKEN

上面 URL 中，token参数就是令牌，A 网站所以直接在前端拿到令牌。

注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是由于 OAuth 2.0 容许跳转网址是 HTTP 协议，所以存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减小了泄漏令牌的风险。

这种方式把令牌直接传给前端，是很不安全的。所以，只能用于一些安全要求不高的场景，而且令牌的有效期必须很是短，一般就是会话期间（session）有效，浏览器关掉，令牌就失效了。

第三种方式：密码式

若是你高度信任某个应用，RFC 6749 也容许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到之后，A 就直接向 B 请求令牌。

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

上面 URL 中，grant_type参数是受权方式，这里的password表示"密码式"，username和password是 B 的用户名和密码。

第二步，B 网站验证身份经过后，直接给出令牌。注意，这时不须要跳转，而是把令牌放在 JSON 数据里面，做为 HTTP 回应，A 所以拿到令牌。

这种方式须要用户给出本身的用户名/密码，显然风险很大，所以只适用于其余受权方式都没法采用的状况，并且必须是用户高度信任的应用。

第四种方式：凭证式

最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

第一步，A 应用在命令行向 B 发出请求。

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 B 确认 A 的身份。

第二步，B 网站验证经过之后，直接返回令牌。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

令牌的使用

A 网站拿到令牌之后，就能够向 B 网站的 API 请求数据了。

此时，每一个发到 API 的请求，都必须带有令牌。具体作法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。

curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"

上面命令中，ACCESS_TOKEN就是拿到的令牌。

更新令牌

令牌的有效期到了，若是让用户从新走一遍上面的流程，再申请一个新的令牌，极可能体验很差，并且也没有必要。OAuth 2.0 容许用户自动更新令牌。

具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另外一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

https://b.com/oauth/token?
  grant_type=refresh_token&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  refresh_token=REFRESH_TOKEN

上面 URL 中，grant_type参数为refresh_token表示要求更新令牌，client_id参数和client_secret参数用于确认身份，refresh_token参数就是用于更新令牌的令牌。

B 网站验证经过之后，就会颁发新的令牌。