本文概述了OAuth 2.0協議。它討論了OAuth 2.0實現過程中涉及的不同參與者和步驟。
介紹：
OAuth代表開放授權。它是一個免費開放的協議，建立在IETF標準和Open Web Foundation的許可之上。它允許使用者與第三方共享其私有資源，同時保密自己的憑據。這些資源可以是照片，視訊，聯絡人列表，位置和計費功能等，並且通常與其他服務提供商一起儲存。OAuth通過在使用者批准訪問許可權時向請求（客戶端）應用程式授予令牌來執行此操作。每個令牌在特定時間段內授予對特定資源的有限訪問許可權。
1. Oauth2是一個授權協議：
OAuth2支援“委派身份驗證”，即授予對其他人或應用程式的訪問許可權以代表您執行操作。考慮一下這種情況：你開車去一家優雅的酒店，他們可能會提供代客泊車服務。然後，您授權代客服務員通過將鑰匙交給他來開車，以便讓他代表您執行操作。
OAuth2的工作方式類似 - 使用者授予對應用程式的訪問許可權，以代表使用者執行有限的操作，並在訪問可疑時撤消訪問許可權。
2.參與OAuth2的參與者：
i）資源伺服器：託管受OAuth2保護的使用者擁有資源的伺服器。資源伺服器驗證訪問令牌並提供受保護資源。
ii）資源所有者：通常，應用程式的使用者是資源所有者。資源所有者能夠授予或拒絕訪問資源伺服器上託管的自己的資料。
iii）授權伺服器：授權伺服器獲得資源所有者的同意，並向客戶端發出訪問令牌以訪問資源伺服器託管的受保護資源。
iv）客戶端：應用程式使API請求代表資源所有者對受保護資源執行操作。在它可以這樣做之前，它必須由資源所有者授權，並且授權必須由資源伺服器/授權伺服器驗證。OAuth2根據其與授權伺服器安全身份驗證的能力（即，維護其客戶端憑據機密性的能力）定義了兩種客戶端型別：
a）機密：客戶能夠保持其憑證的機密性。機密客戶端在安全伺服器上實現，具有對客戶端憑證的受限訪問（例如，在Web伺服器上執行的Web應用程式）。
b）公共：客戶端無法維護其憑據的機密性（例如，已安裝的本機應用程式或基於Web瀏覽器的應用程式），並且無法通過任何其他方式進行安全的客戶端身份驗證。
3.您是應用程式開發人員，這是一個用例：
考慮一個場景。您正在開發一個有趣的Facebook應用程式，並將其稱為“FunApp”。FunApp需要訪問使用者的公開個人資料，照片，帖子，朋友等。現在問題是，FunApp如何獲得使用者從Facebook訪問他/她的資料的許可權，同時告知Facebook使用者已授予此許可權FunApp使Facebook能夠與這個應用程式共享使用者的資料？
舊方式：使用者與FunApp共享他/她的Facebook憑據（使用者名稱，密碼）。這種方法存在一些挑戰：信任，不受限制的訪問，使用者對Facebook密碼的更改等。
OAuth2方式：如果應用需要訪問其使用者資料，Funapp會將使用者重定向到Facebook上的授權頁面。使用者將登入其帳戶並授予訪問許可權，然後FunApp將從Facebook獲取訪問令牌以訪問使用者的資料。雖然Oauth2已經解決了這些挑戰，但它也為開發人員創造了成本。
讓我們從開發人員的角度看這個場景，並找出這裡涉及的演員：
- 由於Facebook擁有所有資源（使用者的公開個人資料，照片，帖子，朋友等），因此它成為資源伺服器。
- 使用者是資源所有者。
- 當FunApp請求使用者的受保護資源時，它將成為客戶端。
- 當Facebook獲得使用者同意並向FunApp發出訪問令牌時，它將成為授權伺服器。
4.註冊客戶端（FunApp）和獲取客戶端憑據：
OAuth要求客戶端向授權伺服器註冊。授權伺服器請求有關客戶端的一些基本資訊，例如name，redirect_uri（授權伺服器在資源所有者授予許可權時將重定向到的URL）並將客戶端憑據（client-id，client-secret）返回給客戶端。在執行諸如交換訪問令牌的授權碼和重新整理訪問令牌等操作時，這些憑證對於保護請求的真實性至關重要。
例如，Facebook要求您在Facebook Developers入口網站上註冊您的客戶端。轉到Facebook開發人員入口網站並註冊FunApp並獲取客戶端憑據。
5.逐步獲取訪問令牌：
FunApp需要從Facebook獲取訪問令牌才能訪問使用者的資料。為了獲得訪問令牌，FunApp將使用者重定向到Facebook的登入頁面。成功登入後，Facebook會重定向到redirect_uri（在步驟4中註冊）以及短期授權程式碼。FunApp交換授權程式碼以獲取長期訪問令牌。訪問令牌用於訪問使用者的資料。這是OAuth2中最受歡迎的流程，稱為授權程式碼授權。以下是在授權程式碼授權中獲取訪問令牌的序列圖：
6. 瞭解授權授權型別：
要獲取訪問令牌，客戶端將從資源所有者獲取授權。授權以授權授權的形式表示，客戶端使用該授權授權來請求訪問令牌。OAuth2定義了四種標準授權型別：授權程式碼，隱式，資源所有者密碼憑據和客戶端憑據。它還提供了一種用於定義其他授權型別的擴充套件機制。
i）授權程式碼授權：此授權型別針對機密客戶端（Web應用程式伺服器）進行了優化。授權程式碼流不會將訪問令牌公開給資源所有者的瀏覽器。相反，使用通過瀏覽器傳遞的中間“授權程式碼”來完成授權。在對受保護的API進行呼叫之前，必須將此程式碼交換為訪問令牌。
ii）隱性撥款：此撥款型別適用於公共客戶。隱式授權流程不適用重新整理令牌。如果授權伺服器定期過期訪問令牌，則只要需要訪問許可權，您的應用程式就需要執行授權流程。在此流程中，在使用者授予所請求的授權後，會立即將訪問令牌返回給客戶端。不需要中間授權程式碼，因為它在授權程式碼授權中。
iii）資源所有者密碼憑證：資源所有者密碼憑證授權型別適用於資源所有者與客戶端具有信任關係並且資源所有者同意與客戶端共享他/她的憑證（使用者名稱，密碼）的情況。然後，客戶端可以使用所有者憑據中的資源從授權伺服器獲取訪問令牌。
iv）客戶端憑據：當客戶端本身擁有資料且不需要資源所有者的委派訪問許可權，或者已經在典型OAuth流程之外授予應用程式委派訪問許可權時，此授權型別是合適的。在此流程中，不涉及使用者同意。客戶端交換其客戶端憑據以獲取訪問令牌。
7.令牌已過期，獲取新的訪問令牌：
如果訪問令牌由於令牌已過期或已被撤銷而不再有效，則使用OAuth 2.0訪問令牌進行API呼叫可能會遇到錯誤。在這種情況下，資源伺服器將返回4xx錯誤程式碼。客戶端可以使用重新整理令牌（在授權程式碼交換訪問令牌時獲得）獲取新的訪問令牌。
8.結論：
這是嘗試提供OAuth 2.0過程的概述，並提供獲取訪問令牌的方法。我希望它有所幫助。
享受整合應用的樂趣！
公眾號:銀河系1號
聯絡郵箱：public@space-explore.com