oauth2.0協議流程

什么是OAuth 2.0

OAuth 2.0是一個已被廣泛采用的委托授權框架，已經存在了很多年，并且似乎已經存在。 如果您不熟悉OAuth 2.0的基本概念，可以使用
川崎孝彥寫的優秀文章 。 這只是OAuth 2.0各方的簡要提醒：

• 資源所有者–受保護資源的所有者，例如用戶
• 客戶端–想要訪問受保護資源的應用程序，例如服務器端Web應用程序或單頁應用程序（SPA）
• 授權服務器–發行令牌的服務器
• 資源服務器–管理資源所有者的受保護數據的服務器

讓我們瀏覽每個OAuth 2.0流程并討論其用法。

客戶證書授予

這是最簡單的流程。 它允許客戶端使用其客戶端ID和客戶端密鑰請求訪問令牌。 兩者都安全地保存在客戶端并在授權服務器中注冊。

第一步，客戶端將HTTP請求發送到授權服務器，包括其客戶端ID和客戶端密鑰（例如，在Authorization標頭中）。 該請求也可以包括所請求的范圍。

在響應中，授權服務器發送訪問令牌。

客戶端使用訪問令牌來調用資源服務器。

什么時候使用？

如您所見，沒有用戶參與。 建議使用“客戶端憑據授予”來進行計算機到計算機的授權。 通常，一個受信任的服務將調用另一個服務。

授權碼授予

最常用的流程，專門為可以維護其客戶端機密信息的服務器端應用程序而設計。 這是基于重定向的流之一。

客戶端通過將資源所有者的用戶代理重定向到授權服務器來啟動流程。 客戶端包括其客戶端ID，請求的范圍和重定向URI。

資源所有者通過授予客戶端請求的權限來授權客戶端。

授權服務器將用戶代理重定向回客戶端（使用來自點1的重定向URI）。 重定向URI包含一個臨時授權碼（作為查詢參數）。

客戶端從授權服務器請求訪問令牌。 該請求包括在上一步中收到的客戶端ID，客戶端密碼和授權代碼。

如果所有內容均有效，則授權服務器將返回訪問令牌，并可選地返回刷新令牌。

客戶端使用訪問令牌代表資源所有者調用資源服務器。

為什么我們需要其他授權碼？

為什么我們不能直接請求訪問令牌？ 為什么首先要引入授權碼？ 事實證明，主要目標是分離公開給客戶和用戶代理的信息。 請注意，訪問令牌根本不會通過瀏覽器。 從客戶端（服務器端應用程序）使用

通過用戶代理轉發的授權碼。 瀏覽器有什么問題？ OAuth 2.0不需要客戶端服務器支持HTTPS。 因此，從技術上講，可能存在無法通過SSL重定向到客戶端服務器的問題。 如果發生這種情況，則通過明文發送授權碼。 如果有人攔截了它，那么沒有Client Secret仍然沒有用。 但是，如果您直接通過HTTP發送訪問令牌，則可能會遭到破壞。

什么時候使用？

如前所述，建議對服務器端Web應用程序使用此流程。 但是，近年來，這種流程的變體也已用于單頁和移動應用程序。

單頁應用

對于單頁應用程序，唯一的區別是客戶端（SPA）沒有客戶端密鑰。 由于SPA在瀏覽器中運行，并且其源代碼是公開的，因此無法在瀏覽器端對客戶端機密保密。 這就是為什么在上圖的第4步中，將授權代碼交換為訪問令牌而不發送客戶端密鑰。

原生移動應用

與SPA類似，本機移動應用程序被認為是公共的，而不是機密的客戶端。 這就是客戶端機密不應該存儲在移動設備中（因此在請求訪問令牌時不發送的原因）。 沒有在移動設備中實現沒有客戶端密鑰的授權代碼流，可能會存在一些安全問題。 這樣的問題之一是，授權碼可能會被攻擊者攔截并交換為訪問令牌。 為了減輕這種風險，有一種稱為代碼交換證明密鑰（PKCE）的技術。 對于每個授權請求，客戶端都必須創建一個稱為Code Verifier的隨機密鑰。 授權代碼請求中包含其稱為Code Challenge的哈希版本。 授權服務器應將此代碼質詢與其生成的授權代碼相關聯。 以后，當為訪問令牌交換授權碼時，客戶端將代碼驗證程序作為查詢參數。 除了驗證標準參數外，授權服務器還應使用先前收到的Code Challenge驗證Code Verifier。

客戶端移動應用打開帶有授權請求的瀏覽器。 授權請求包括客戶端ID，請求的范圍，重定向URI和代碼質詢。

授權請求發送到身份驗證服務器

資源所有者授權客戶。

結果，授權碼被返回給用戶代理。

授權碼被傳遞給客戶端。

客戶端應用將授權代碼和代碼驗證程序以及重定向URI和客戶端ID發送到授權服務器。

授權服務器將代碼驗證程序的哈希值與先前發送的代碼質詢進行比較。 如果它們匹配，則將授權代碼交換為訪問令牌（以及可選的刷新令牌）

客戶端使用訪問令牌代表資源所有者調用資源服務器。

此外， 當前的最佳實踐是僅使用外部用戶代理（而不是嵌入式Web視圖）來發送對授權碼的請求。

隱性補助

它類似于“授權代碼授予”，但完全跳過了“授權代碼”步驟。 客戶端直接請求訪問令牌，不需要授權碼。 此外，不涉及“客戶機密”。 在隱式授予中，不使用刷新令牌。 重要的是要提到，訪問令牌以散列片段的形式在3xx重定向中返回，并且永遠不會從瀏覽器發送。

什么時候使用？

它最初設計為SPA的流程。 它依賴于瀏覽器，可能無法在其他環境中安全地實現。 但是，如前所述，對于SPA，近年來，越來越多的組織已經朝著沒有客戶機密而不是隱式流程的授權代碼流發展。

資源所有者密碼憑證授予

在此流程中，資源所有者將其憑據直接提交到客戶端應用程序。 客戶端應用程序使用該憑據直接將它們交換為訪問令牌（以及可選的刷新令牌）。 與客戶端憑據類似，它不是基于重定向的流程。

資源所有者將其憑據提交到客戶端應用程序。

客戶端將憑據轉發到授權服務器。

授權服務器返回訪問令牌（以及可選的刷新令牌）

客戶端使用訪問令牌代表資源所有者調用資源服務器。

什么時候使用？

資源所有者和客戶端應用程序之間是否高度信任。 建議僅在不可能進行其他處理時才使用它。 現在，設備流擴展可以涵蓋資源所有者密碼憑據授予的大多數原始用例。

設備流程

這是OAuth 2.0中新增的擴展流，用于覆蓋設備具有Internet連接但沒有瀏覽器或輸入文字的輸入能力受限的情況，例如電視。

在此流程中，設備要求用戶使用瀏覽器（例如智能手機）在設備上打開特定的URL以便進行授權。

摘要

這是設計用于給定場景的流程的快速摘要：

• 服務器到服務器：客戶端憑據流
• 服務器端應用程序：授權代碼流
• SPA：沒有客戶端機密或隱式流的授權代碼流
• 移動設備：PKCE的授權碼流
• 沒有瀏覽器的設備：設備流
  

翻譯自: https://www.javacodegeeks.com/2019/01/right-flow-job-oauth-2-0-flow-should-use.html

oauth2.0協議流程

總結

以上是生活随笔為你收集整理的oauth2.0协议流程_正确的工作流程：我应该使用哪个OAuth 2.0流程？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。