OAuth 2.0詳解（Google api示例）
流程
Google Workspace API 的身份驗證和授權的簡要步驟：
- 配置您的 Google Cloud 項目和應用程序：在開發期間，您在 Google Cloud Console 中注冊您的應用程序，定義授權范圍和訪問憑據，以使用 API 密鑰、最終用戶憑據或服務帳戶憑據對您的應用程序進行身份驗證。
- 驗證您的應用程序的訪問權限：當您的應用程序運行時，將評估注冊的訪問憑據。如果您的應用程序正在以最終用戶身份進行身份驗證，則可能會顯示登錄提示。
- 請求資源：當您的應用需要訪問 Google 資源時，它會使用您之前注冊的相關訪問范圍向 Google 詢問。
- 征求用戶同意：如果您的應用作為最終用戶進行身份驗證，Google 會顯示 OAuth 同意屏幕，以便用戶決定是否授予您的應用訪問所請求數據的權限。
- 發送已批准的資源請求：如果用戶同意訪問范圍，您的應用會將憑據和用戶批准的訪問范圍捆綁到請求中。該請求被發送到 Google 授權服務器以獲取訪問令牌。
- Google 返回訪問令牌：訪問令牌包含授予的訪問范圍列表。如果返回的范圍列表比請求的訪問范圍更受限制，您的應用程序將禁用令牌限制的任何功能。
- 訪問請求的資源：您的應用使用來自 Google 的訪問令牌來調用相關 API 並訪問資源。
- 獲取刷新令牌（可選）：如果您的應用需要在單個訪問令牌的生命周期之外訪問 Google API，則可以獲取刷新令牌。
- 請求更多資源：如果需要額外的訪問權限，您的應用會要求用戶授予新的訪問范圍，從而產生獲取訪問令牌的新請求（步驟 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 的驗證）：
刷新token
如果剛剛獲取的token過期了（Google的是一個小時），我們可以用剛剛拿到的refresh_token去token_url請求更新token，當然，如果refresh_token也過期了，就只能重新讓用戶授權了（一般過期時間會選得長一點）。
請求的url為token_url，方式為post，參數如下：
- grant_type：表示使用的是授權模式，此處值固定為refresh_token；
- refresh_token：表示早前收到的更新令牌；
- scope：表示申請的授權范圍，不可以超出上一次申請的范圍；
- client_id和client_secret同上。