本篇內容介紹了“auth2.0四種授權模式分別是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

創(chuàng)新互聯(lián)是專業(yè)的恭城網(wǎng)站建設公司，恭城接單;提供成都做網(wǎng)站、成都網(wǎng)站設計,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行恭城網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

OAuth 2.0 的標準是 RFC 6749 文件 。

OAuth 2.0 規(guī)定了四種獲得令牌的流程。你可以選擇最適合自己的那一種，向第三方應用頒發(fā)令牌。下面就是這四種授權方式。

• 授權碼（authorization-code）

• 隱藏式（implicit）

• 密碼式（password）：

• 客戶端憑證（client credentials）

注意，不管哪一種授權方式，第三方應用申請令牌之前，都必須先到系統(tǒng)備案，說明自己的身份，然后會拿到兩個身份識別碼：客戶端 ID（client ID）和客戶端密鑰（client secret）。這是為了防止令牌被濫用，沒有備案過的第三方應用，是不會拿到令牌的。

第一種授權方式：授權碼

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

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

第一步，A 網(wǎng)站提供一個鏈接，用戶點擊后就會跳轉到 B 網(wǎng)站，授權用戶數(shù)據(jù)給 A 網(wǎng)站使用。下面就是 A 網(wǎng)站跳轉 B 網(wǎng)站的一個示意鏈接。

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

上面 URL 中，response_type參數(shù)表示要求返回授權碼（code），client_id參數(shù)讓 B 知道是誰在請求，redirect_uri參數(shù)是 B 接受或拒絕請求后的跳轉網(wǎng)址，scope參數(shù)表示要求的授權范圍（這里是只讀）。

第二步，用戶跳轉后，B 網(wǎng)站會要求用戶登錄，然后詢問是否同意給予 A 網(wǎng)站授權。用戶表示同意，這時 B 網(wǎng)站就會跳回redirect_uri參數(shù)指定的網(wǎng)址。跳轉時，會傳回一個授權碼，就像下面這樣。

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

上面 URL 中，code參數(shù)就是授權碼。

第三步，A 網(wǎng)站拿到授權碼以后，就可以在后端，向 B 網(wǎng)站請求令牌。

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參數(shù)和client_secret參數(shù)用來讓 B 確認 A 的身份（client_secret參數(shù)是保密的，因此只能在后端發(fā)請求），grant_type參數(shù)的值是AUTHORIZATION_CODE，表示采用的授權方式是授權碼，code參數(shù)是上一步拿到的授權碼，redirect_uri參數(shù)是令牌頒發(fā)后的回調網(wǎng)址。

第四步，B 網(wǎng)站收到請求以后，就會頒發(fā)令牌。具體做法是向redirect_uri指定的網(wǎng)址，發(fā)送一段 JSON 數(shù)據(jù)。

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

上面 JSON 數(shù)據(jù)中，access_token字段就是令牌，A 網(wǎng)站在后端拿到了。

第二種方式：隱藏式

有些 Web 應用是純前端應用，沒有后端。這時就不能用上面的方式了，必須將令牌儲存在前端。RFC 6749 就規(guī)定了第二種方式，允許直接向前端頒發(fā)令牌。這種方式?jīng)]有授權碼這個中間步驟，所以稱為（授權碼）"隱藏式"（implicit）。

第一步，A 網(wǎng)站提供一個鏈接，要求用戶跳轉到 B 網(wǎng)站，授權用戶數(shù)據(jù)給 A 網(wǎng)站使用。

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

上面 URL 中，response_type參數(shù)為token，表示要求直接返回令牌。

第二步，用戶跳轉到 B 網(wǎng)站，登錄后同意給予 A 網(wǎng)站授權。這時，B 網(wǎng)站就會跳回redirect_uri參數(shù)指定的跳轉網(wǎng)址，并且把令牌作為 URL 參數(shù)，傳給 A 網(wǎng)站。

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

上面 URL 中，token參數(shù)就是令牌，A 網(wǎng)站因此直接在前端拿到令牌。

注意，令牌的位置是 URL 錨點（fragment），而不是查詢字符串（querystring），這是因為 OAuth 2.0 允許跳轉網(wǎng)址是 HTTP 協(xié)議，因此存在"中間人攻擊"的風險，而瀏覽器跳轉時，錨點不會發(fā)到服務器，就減少了泄漏令牌的風險。

這種方式把令牌直接傳給前端，是很不安全的。因此，只能用于一些安全要求不高的場景，并且令牌的有效期必須非常短，通常就是會話期間（session）有效，瀏覽器關掉，令牌就失效了。

第三種方式：密碼式

如果你高度信任某個應用，RFC 6749 也允許用戶把用戶名和密碼，直接告訴該應用。該應用就使用你的密碼，申請令牌，這種方式稱為"密碼式"（password）。

第一步，A 網(wǎng)站要求用戶提供 B 網(wǎng)站的用戶名和密碼。拿到以后，A 就直接向 B 請求令牌。

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

上面 URL 中，grant_type參數(shù)是授權方式，這里的password表示"密碼式"，username和password是 B 的用戶名和密碼。

第二步，B 網(wǎng)站驗證身份通過后，直接給出令牌。注意，這時不需要跳轉，而是把令牌放在 JSON 數(shù)據(jù)里面，作為 HTTP 回應，A 因此拿到令牌。

這種方式需要用戶給出自己的用戶名/密碼，顯然風險很大，因此只適用于其他授權方式都無法采用的情況，而且必須是用戶高度信任的應用。

第四種方式：憑證式

最后一種方式是憑證式（client credentials），適用于沒有前端的命令行應用，即在命令行下請求令牌。

第一步，A 應用在命令行向 B 發(fā)出請求。

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

上面 URL 中，grant_type參數(shù)等于client_credentials表示采用憑證式，client_id和client_secret用來讓 B 確認 A 的身份。

第二步，B 網(wǎng)站驗證通過以后，直接返回令牌。

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

令牌的使用

A 網(wǎng)站拿到令牌以后，就可以向 B 網(wǎng)站的 API 請求數(shù)據(jù)了。

此時，每個發(fā)到 API 的請求，都必須帶有令牌。具體做法是在請求的頭信息，加上一個Authorization字段，令牌就放在這個字段里面。

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

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

更新令牌

令牌的有效期到了，如果讓用戶重新走一遍上面的流程，再申請一個新的令牌，很可能體驗不好，而且也沒有必要。OAuth 2.0 允許用戶自動更新令牌。

具體方法是，B 網(wǎng)站頒發(fā)令牌的時候，一次性頒發(fā)兩個令牌，一個用于獲取數(shù)據(jù)，另一個用于獲取新的令牌（refresh token 字段）。令牌到期前，用戶使用 refresh token 發(fā)一個請求，去更新令牌。

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

上面 URL 中，grant_type參數(shù)為refresh_token表示要求更新令牌，client_id參數(shù)和client_secret參數(shù)用于確認身份，refresh_token參數(shù)就是用于更新令牌的令牌。

B 網(wǎng)站驗證通過以后，就會頒發(fā)新的令牌。

“auth2.0四種授權模式分別是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質量的實用文章！

網(wǎng)頁名稱：auth2.0四種授權模式分別是什么
文章轉載：http://chinadenli.net/article38/goeipp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供用戶體驗、面包屑導航、建站公司、企業(yè)建站、、軟件開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)