OAuth - four ways - Code World

OAuth 2.0 standard is RFC 6749 document. The document first explains what OAuth Yes.

OAuth introduces a layer of authorization, used to separate two different roles: the client and the resource owners. After ...... resource owner consent, resource server can issue a token to the client. 
By client token to request data.

Meaning of this passage is that the core issue is the OAuth token to the third-party applications. Then, RFC 6749 goes on to write:

As the Internet has a variety of scenarios) This standard defines four ways to get authorization token (authorization grant).

In other words, OAuth 2.0 defines four process get tokens. You can choose the one that best suits your issued token to the third-party applications. Here are four License.

Authorization code (authorization-code)
Hidden (implicit)
Type the password (password):
The client certificate (client credentials)

Note that regardless of what kind of License, third-party applications to apply before the token must first come first filing system, identify themselves, and then will get two identification code: Client ID (client ID) and client secret key (client secret). This is to prevent abuse of the token, had no record of third-party applications will not get the token.

The first Authorization: Authorization Code

Authorization code (authorization code) mode refers to a third-party application to request an authorization code, and then use the acquired token code.

This approach is most commonly used process, safety is the highest, it is suitable for those who have back-end Web application. Authorization code transmitted through the front, the token is stored at the rear end, and all communications with the server resources are completed at the rear end. Such separate front and rear ends, the token can avoid leakage.

The first step, A website provides a link, it will jump to the B site after the user clicks, the user authorization data to the A-site uses. Here is a schematic Jump A site B links to site.

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

In the above URL, response_typethe parameter indicates that the requested authorization code to return ( code), client_idthe parameter B know who to let in the request, redirect_urithe parameter B is the URL of a jump to accept or reject the request, scopethe parameter indicates that the requested authorization range (here, read only).

The second step, after the user to jump, B sites require users to log in and then asked if agreed to give the A site license. The user agrees, then the site will jump back to the B redirect_uriparameter specifies the URL. Jump, returns an authorization code, like this below.

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

The above URL, the codeparameter is the authorization code.

The third step, A to get the website after the authorization code, can be at a rear end, a request token to the B-site.

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

In the above URL, client_idparameters, and client_secretparameters to confirm the identity of A to B so that ( client_secretthe parameter is confidential, so only the rear end reQuest), grant_typethe value of the parameter is AUTHORIZATION_CODE, the License is represented using the authorization code, codethe parameter is to take the step to the authorization code, redirect_urithe parameter is the callback URL tokens issued.

The fourth step, after the B site receives a request, it will issue a token. The specific approach is to redirect_urispecify a URL, send some JSON data.

{    
  "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 网站验证通过以后，就会颁发新的令牌。