OAuth 2.0詳解（Google api示例）

流程

Google Workspace API 的身份驗證和授權的簡要步驟：

1. 配置您的 Google Cloud 專案和應用程式：在開發期間，您在 Google Cloud Console 中註冊您的應用程式，定義授權範圍和訪問憑據，以使用 API 金鑰、終端使用者憑據或服務帳戶憑據對您的應用程式進行身份驗證。
2. 驗證您的應用程式的訪問許可權：當您的應用程式執行時，將評估註冊的訪問憑據。如果您的應用程式正在以終端使用者身份進行身份驗證，則可能會顯示登入提示。
3. 請求資源：當您的應用需要訪問 Google 資源時，它會使用您之前註冊的相關訪問範圍向 Google 詢問。
4. 徵求使用者同意：如果您的應用作為終端使用者進行身份驗證，Google 會顯示 OAuth 同意螢幕，以便使用者決定是否授予您的應用訪問所請求資料的許可權。
5. 傳送已批准的資源請求：如果使用者同意訪問範圍，您的應用會將憑據和使用者批准的訪問範圍捆綁到請求中。該請求被髮送到 Google 授權伺服器以獲取訪問令牌。
6. Google 返回訪問令牌：訪問令牌包含授予的訪問範圍列表。如果返回的範圍列表比請求的訪問範圍更受限制，您的應用程式將禁用令牌限制的任何功能。
7. 訪問請求的資源：您的應用使用來自 Google 的訪問令牌來呼叫相關 API 並訪問資源。
8. 獲取重新整理令牌（可選）：如果您的應用需要在單個訪問令牌的生命週期之外訪問 Google API，則可以獲取重新整理令牌。
9. 請求更多資源：如果需要額外的訪問許可權，您的應用會要求使用者授予新的訪問範圍，從而產生獲取訪問令牌的新請求（步驟 3-6）。

術語解釋

1. 驗證（authentication）

確保委託人（principal）（可以是使用者或代表使用者行事的應用程式）與他們所說的一樣的行為。在編寫 Google Workspace 應用程式時，您應該注意以下型別的身份驗證：

1.1 使用者認證（user authentication）

使用者對您的應用進行身份驗證（登入）的行為。使用者身份驗證通常通過登入過程執行，在該過程中，使用者使用使用者名稱和密碼組合嚮應用程式驗證其身份。可以使用Sign In With Google

1.2 應用認證（app authentication）

應用代表執行應用的使用者直接向 Google 服務進行身份驗證的行為。應用程式身份驗證通常使用應用程式程式碼中預先建立的憑據來執行。

2. 授權（authorization）

主體必須訪問資料或執行操作的許可權或“許可權”。授權行為是通過您在應用程式中編寫的程式碼執行的。此程式碼通知使用者該應用希望代表他們執行操作，如果允許，它會使用您應用的唯一憑據 從 Google 獲取用於訪問資料或執行操作的訪問令牌。

3. 憑據（credentials）

用於軟體安全的一種標識形式。在身份驗證方面，憑據通常是使用者名稱/密碼組合。就 Google Workspace API 的授權而言，憑據通常是某種形式的標識，例如唯一的祕密字串，只有在應用開發者和身份驗證伺服器之間才知道。Google 支援以下身份驗證憑據：API 金鑰、OAuth 2.0 客戶端 ID 和服務帳戶。

3.1 API 金鑰（API Key）

用於請求訪問公共資料的憑據，例如使用 Maps API 提供的資料或使用 Google Workspace 共享設定中的“網際網路上知道此連結的任何人”設定共享的 Google Workspace 檔案。

3.2 OAuth 2.0 客戶端 ID（OAuth 2 client ID）

用於請求訪問使用者擁有的資料的憑據。這是使用 Google Workspace API 請求訪問資料時使用的主要憑據。此憑據需要使用者同意。

3.3 client secret

只有您的應用程式和授權伺服器才應該知道的字串。客戶端金鑰通過僅將令牌授予授權請求者來保護使用者的資料。你永遠不應該在你的應用程式中包含你的客戶端密碼。

3.4 service account keys

服務帳戶用於獲得對 Google 服務的授權。

3.5 服務帳戶（service account）

用於伺服器到伺服器互動的憑據，例如作為程序執行以訪問某些資料或執行某些操作的匿名應用程式。服務帳戶通常用於訪問基於雲的資料和操作。但是，當與域範圍的授權一起使用時，它們可用於訪問使用者資料。

整體思路

OAuth在"客戶端"與"服務提供商"之間，設定了一個授權層（authorization layer）。"客戶端"不能直接登入"服務提供商"，只能登入授權層，以此將使用者與客戶端區分開來。"客戶端"登入授權層所用的令牌（token），與使用者的密碼不同。使用者可以在登入的時候，指定授權層令牌的許可權範圍和有效期。

"客戶端"登入授權層以後，"服務提供商"根據令牌的許可權範圍和有效期，向"客戶端"開放使用者儲存的資料。

授權模式

客戶端必須得到使用者的授權（authorization grant），才能獲得令牌（access token）。OAuth 2.0定義了四種授權方式。

• 授權碼模式（authorization code）
• 簡化模式（implicit）
• 密碼模式（resource owner password credentials）
• 客戶端模式（client credentials）

授權碼模式操作步驟（重點）

接下來用Google api官方的操作步驟來講解剛剛說到的9個流程（這裡只重點說前七個）

配置 Google Cloud 專案和應用程式

也就是在 Google控制檯去新增一個oauth2.0憑證（credential）

填寫好必要的資料之後（注意這裡有一個 redirect_url 的設定，這裡要配置之後我們引數裡面的 redirect_url，不然無法訪問，當然隨便一個都行）

建立完畢之後可以下載到本地下來，裡面的內容就是我們後續獲取token的根據，格式是：

{
   "web":{
      "client_id":"YOUR_CLIENT_ID",
      "project_id":"PROJECT_ID",
      "auth_uri":"https://accounts.google.com/o/oauth2/auth",
      "token_uri":"https://oauth2.googleapis.com/token",
      "auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs",
      "client_secret":"YOUR_CLIENT_SECRET"
   }
}

驗證您的應用程式的訪問許可權

這個階段，客戶端會向認證伺服器（注意不是使用者）傳送請求，地址就是剛剛的 auth_url，方式為get，有以下幾個params：

• response_type：表示授權型別，此處的值固定為"code"；
• client_id：表示客戶端的ID；
• redirect_uri：表示重定向URI（注意要是剛剛在Google console配置過的）
• scope：表示申請的許可權範圍（這裡我要使用gmail api，去看官網發現是以上的地址）
• access_type。

用postman來看看：

用瀏覽器訪問之後可以看到如下認證頁面，使用者點選認證之後就會從伺服器返回資料中得到一個code（這裡有個比較容易遇到的問題，就是由於我們的應用還沒有Google授權，所以要將使用者新增到後臺的測試名單裡 專案主持人也不例外）：

客戶端向認證伺服器申請令牌的HTTP請求

就是向 token_url 傳送post請求，引數要帶上剛剛的 code（這個code只能用一次，用多次會出現 invalid_grant 的錯誤） ：

• grant_type：表示使用的授權模式，此處的值固定為"authorization_code"；
• code：表示上一步獲得的授權碼；
• redirect_uri：表示重定向URI，且必須與上面中的該引數值保持一致。
• client_id：表示客戶端ID；
• client_secret：表示客戶端secret。

expires_in：表示過期時間，單位為秒；

• refresh_token：表示更新令牌，用來獲取下一次的訪問令牌；
• scope：表示許可權範圍。

訪問請求的資源

好啦，現在我們終於拿到token了，帶上這個token，就能使用相關 Google api了。

如，我這裡是要使用 gmail 的api，剛剛也申請了相關許可權範圍（https://mail.google.com/），參照官網的格式傳送請求（設定好 OAuth 的驗證）：

阮一峰理解OAuth 2.0
Google文件