OAuth登錄的四種方式

1. 授權碼

授權碼（authorization code）方式，指的是第三方應用先申請一個授權碼，然后再用該碼獲取令牌。

這種方式是最常用的流程，安全性也最高，它適用于那些有后端的 Web 應用。授權碼通過前端傳送，令牌則是儲存在后端，而且所有與資源服務器的通信都在后端完成。這樣的前后端分離，可以避免令牌泄漏。

例如，有一個網站A（高德地圖），需要向網站B（微博）授權登錄

第一步，拿到授權碼

A 網站（高德）提供一個鏈接，用戶點擊后就會跳轉到 B（微博） 網站，授權用戶數據給 A（高德） 網站使用。下面就是 A （高德）網站跳轉 B （微博）網站的一個示意鏈接。

https://api.weibo.com/oauth2/authorize?
client_id=884965267
&redirect_uri=https%3A%2F%2Fid.amap.com%2Findex%2Fweibo%3Fpassport%3D1

client_id客戶端id,redirect_uri跳轉鏈接

第二步，在用戶跳轉后，B 網站會要求用戶登錄，然后詢問是否同意給予 A（高德） 網站授權。用戶表示同意，這時 B （微博）網站就會跳回redirect_uri參數指定的網址。

跳轉時，會傳回一個授權碼，就像下面這樣。

https%3A%2F%2Fid.amap.com%2Findex%2Fweibo%3Fpassport%3D1?
code=******

第三步，A （高德）網站拿到授權碼以后，就可以在后端，向 B （微博）網站請求令牌。

https://api.weibo.com/oauth2/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":{...}
    }

access_token就是我們所需要的令牌，這個信息在A（高德）網站的后端得到，即可進行用戶的登錄認證

因此，這種方式的登錄模式圖為：

這種登錄一般應用于前后端分離登錄，安全性非常的高，使用也是最廣泛的一種

2. 隱藏式

有些 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 網站因此直接在前端拿到令牌。

這種方式的相對于上一種方式，更加簡單，但是也更加不安全，所有的代碼和登錄都寫在前端頁面中，容易被他人破解，所以一般用于安全性不高的地方。

3. 密碼式

如果你高度信任某個應用，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 因此拿到令牌。

這種方式風險很大，需要直接提供賬號密碼，所以只適用于其他授權方式都無法采用的情況，而且必須是用戶高度信任的應用。

4. 憑證式

最后一種方式是憑證式（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 網站驗證通過以后，直接返回令牌。

這種方式給出的令牌，是針對第三方應用的，而不是針對用戶的，即有可能多個用戶共享同一個令牌。

這種認證場景通常用于調用第三方接口，例如調用阿里云的短信接口等等

文章參考OAuth 2.0 的四種方式