摘要：而在這背后則是建立在基礎(chǔ)之上。簡化模式的授權(quán)許可簡化模式的授權(quán)更加適用于移動端的以及應(yīng)用，因為他們的安全性并不能夠得到保證。除此之外，服務(wù)也不會對應(yīng)用的做唯一性表示驗證，依賴回調(diào)的地址。

在日常的網(wǎng)站中，我們經(jīng)常會看見一些來自社交網(wǎng)站的登錄按鈕，類似使用facebook，twitter登錄等。而在這背后則是建立在OAuth基礎(chǔ)之上。OAuth2是一套提供授權(quán)功能的框架，通過它我們可以使第三方站點獲取到我們的用戶授權(quán)，就像可以拿到facebook 或者微博的用戶昵稱和頭像。OAuth2 提供了包括桌面，web以及移動端應(yīng)用的授權(quán)功能。

授權(quán)一般會定義下面四種身份:

用戶

客戶端

資源服務(wù)器

授權(quán)服務(wù)器

我們通常定義資源的所有者(Resource Owner)即是我們的用戶，是他們允許這些應(yīng)用去訪問他們自己的賬戶信息。當(dāng)然這些應(yīng)用所能訪問的權(quán)限是有限的，它被限制在一個受保護的作用域內(nèi)（比如只能讀取信息，當(dāng)然這取決于我們自己的設(shè)計）.

用戶請求授權(quán)服務(wù)后成功后，會返回一個aceess token給應(yīng)用，這樣應(yīng)用再訪問其他接口服務(wù)時候都需要這個憑證.

客戶端應(yīng)用既是用戶當(dāng)前所用的這個產(chǎn)品了。它通過它用戶授權(quán)成功后，可以對用戶的一些信息進行訪問或者修改，但無論如何，再請求用戶信息的時候，我們的api和授權(quán)服務(wù)必須對它進行合法性驗證。

使用授權(quán)之前，你必須讓這些客戶端應(yīng)用登記在案,你需要它提供一些基本的信息名稱比如，應(yīng)用名稱，網(wǎng)站地址，回調(diào)地址等等。其中回調(diào)地址既是用戶完成授權(quán)后跳向的地址，在那里應(yīng)用能夠處理我們返回的授權(quán)代碼以及access tokens.

當(dāng)應(yīng)用注冊完成后，我們會頒布給應(yīng)用一個授權(quán)證書，里面大致記錄了客戶端的唯一識別(client identifier)和客戶端的安全碼(client secret).
Client ID 是一串暴漏的字符串，用戶構(gòu)建訪問的url以及用于服務(wù)器的驗證。Client Secret則被用來認(rèn)證應(yīng)用的唯一性，從而保證應(yīng)用和api服務(wù)的私秘性。

在前面的流程中，第一步使是獲取授權(quán)許可和acess token.授權(quán)許可的類型取決于用戶的請求類型。OAuth 2 定義了下面的四種許可類型，它們試用于不同情形。

授權(quán)碼，常用于服務(wù)端；

簡化模式，常用于移動設(shè)備上；

用戶密碼驗證，常用于哪些比較信任的服務(wù)，比如團隊內(nèi)的項目；

客戶端驗證，用于應(yīng)用api訪問；

目前大多數(shù)服務(wù)端的app授權(quán)都適用此方式，它會維護一個 client secret。應(yīng)用通過客戶端（比如瀏覽器）去獲取API的授權(quán)碼；

1.用戶會收到一個授權(quán)的url，里面大概會帶上一些基本信息，比如

client_id(應(yīng)用id),redirect_uri(回調(diào)的地址),response_type(許可類型，類似response_type=code)等

2.用戶授權(quán)應(yīng)用，點擊鏈接，用戶會進入授權(quán)的界面，會需要用戶確認(rèn)接受活著拒絕該應(yīng)用的授權(quán)請求。

3.如果用戶點擊了確認(rèn)授權(quán)會掉轉(zhuǎn)到回調(diào)的url，然后帶上授權(quán)碼。

http://yousite.com?code=AUTHORIZATION_CODE

4.應(yīng)用獲取access_token,應(yīng)用會請求某個api獲取用于訪問接口的access_token。

5.應(yīng)用會接受到接口的響應(yīng)，獲取到access_token,有些應(yīng)用還會帶上refresh_token。

當(dāng)然拿到access_token后，應(yīng)用就有權(quán)限去訪問開放的一些接口，如果接口過期了，則需要重新授權(quán)。如果
返回了帶有refresh_token,則通過refresh_token可以請求一個新的則需要重新獲取新的access_token。

簡化模式的授權(quán)更加適用于移動端的App以及Web應(yīng)用，因為他們的安全性并不能夠得到保證。同樣的也是一個簡單的流程，
只是access_token直接返回給客戶端，這樣access_token會直接暴露給用戶，以及設(shè)備上的其他應(yīng)用。除此之外，服務(wù)也不會對
應(yīng)用的做唯一性表示驗證，依賴回調(diào)的地址。

簡化模式的授權(quán)不支持 refresh_token!

應(yīng)用首先會通過一個鏈接去請求token;

用戶點擊鏈接后會跳轉(zhuǎn)到授權(quán)的界面，詢問用戶許可；

用戶許可后會直接帶上access_token條會到原地址類似下面：

http://yoursite.com?access_token=ACCESS_TOKEN

客戶端會將帶過來的token保存起來，比如localstorage,cookie;

應(yīng)用請求其他的api則都會帶上這個access_token了。

這個形式就是直接將用戶賬戶和密碼拿到后去訪問服務(wù)，然后拿到access_token,一般這種模式只用于自己的信任的服務(wù)，

比如自己家的產(chǎn)品或者桌面應(yīng)用等。

應(yīng)用在拿到用戶的密碼會請求一個地址帶上這些數(shù)據(jù)

http://oauth.api.xxxx.com?username=USERNAME&password=PASSWORD&clientID=1232112

驗證成功后，授權(quán)服務(wù)會返回一個access_token,那么現(xiàn)在這個應(yīng)用就算授權(quán)成功。

客戶端驗證主要是提供一個方式讓應(yīng)用去訪問自己的服務(wù)賬號,去更新一些描述信息或者回調(diào)地址等。通過請求一個地址帶上自己的信任然后去取得一個access_token.

一般access_token都有個時間期限，過期了，訪問其他服務(wù)則會受限制，這個時候有的會提供一個獲取新token的接口，你只需帶上refresh_token
以及客戶端的其他信息。

理解OAuth 2.0

An Introduction to OAuth 2

The OAuth 2.0 Authorization Framework

hello.js

Thanks ! 圖片設(shè)計來源于Digital Ocean