oauth2.0協(xié)議流程

什么是OAuth 2.0

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

• 資源所有者–受保護(hù)資源的所有者，例如用戶
• 客戶端–想要訪問受保護(hù)資源的應(yīng)用程序，例如服務(wù)器端Web應(yīng)用程序或單頁應(yīng)用程序（SPA）
• 授權(quán)服務(wù)器–發(fā)行令牌的服務(wù)器
• 資源服務(wù)器–管理資源所有者的受保護(hù)數(shù)據(jù)的服務(wù)器

讓我們?yōu)g覽每個OAuth 2.0流程并討論其用法。

客戶證書授予

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

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

在響應(yīng)中，授權(quán)服務(wù)器發(fā)送訪問令牌。

客戶端使用訪問令牌來調(diào)用資源服務(wù)器。

什么時候使用？

如您所見，沒有用戶參與。 建議使用“客戶端憑據(jù)授予”來進(jìn)行計(jì)算機(jī)到計(jì)算機(jī)的授權(quán)。 通常，一個受信任的服務(wù)將調(diào)用另一個服務(wù)。

授權(quán)碼授予

最常用的流程，專門為可以維護(hù)其客戶端機(jī)密信息的服務(wù)器端應(yīng)用程序而設(shè)計(jì)。 這是基于重定向的流之一。

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

資源所有者通過授予客戶端請求的權(quán)限來授權(quán)客戶端。

授權(quán)服務(wù)器將用戶代理重定向回客戶端（使用來自點(diǎn)1的重定向URI）。 重定向URI包含一個臨時授權(quán)碼（作為查詢參數(shù)）。

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

如果所有內(nèi)容均有效，則授權(quán)服務(wù)器將返回訪問令牌，并可選地返回刷新令牌。

客戶端使用訪問令牌代表資源所有者調(diào)用資源服務(wù)器。

為什么我們需要其他授權(quán)碼？

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

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

什么時候使用？

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

單頁應(yīng)用

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

原生移動應(yīng)用

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

客戶端移動應(yīng)用打開帶有授權(quán)請求的瀏覽器。 授權(quán)請求包括客戶端ID，請求的范圍，重定向URI和代碼質(zhì)詢。

授權(quán)請求發(fā)送到身份驗(yàn)證服務(wù)器

資源所有者授權(quán)客戶。

結(jié)果，授權(quán)碼被返回給用戶代理。

授權(quán)碼被傳遞給客戶端。

客戶端應(yīng)用將授權(quán)代碼和代碼驗(yàn)證程序以及重定向URI和客戶端ID發(fā)送到授權(quán)服務(wù)器。

授權(quán)服務(wù)器將代碼驗(yàn)證程序的哈希值與先前發(fā)送的代碼質(zhì)詢進(jìn)行比較。 如果它們匹配，則將授權(quán)代碼交換為訪問令牌（以及可選的刷新令牌）

客戶端使用訪問令牌代表資源所有者調(diào)用資源服務(wù)器。

此外， 當(dāng)前的最佳實(shí)踐是僅使用外部用戶代理（而不是嵌入式Web視圖）來發(fā)送對授權(quán)碼的請求。

隱性補(bǔ)助

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

什么時候使用？

它最初設(shè)計(jì)為SPA的流程。 它依賴于瀏覽器，可能無法在其他環(huán)境中安全地實(shí)現(xiàn)。 但是，如前所述，對于SPA，近年來，越來越多的組織已經(jīng)朝著沒有客戶機(jī)密而不是隱式流程的授權(quán)代碼流發(fā)展。

資源所有者密碼憑證授予

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

資源所有者將其憑據(jù)提交到客戶端應(yīng)用程序。

客戶端將憑據(jù)轉(zhuǎn)發(fā)到授權(quán)服務(wù)器。

授權(quán)服務(wù)器返回訪問令牌（以及可選的刷新令牌）

客戶端使用訪問令牌代表資源所有者調(diào)用資源服務(wù)器。

什么時候使用？

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

設(shè)備流程

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

在此流程中，設(shè)備要求用戶使用瀏覽器（例如智能手機(jī)）在設(shè)備上打開特定的URL以便進(jìn)行授權(quán)。

摘要

這是設(shè)計(jì)用于給定場景的流程的快速摘要：

• 服務(wù)器到服務(wù)器：客戶端憑據(jù)流
• 服務(wù)器端應(yīng)用程序：授權(quán)代碼流
• SPA：沒有客戶端機(jī)密或隱式流的授權(quán)代碼流
• 移動設(shè)備：PKCE的授權(quán)碼流
• 沒有瀏覽器的設(shè)備：設(shè)備流
  

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

oauth2.0協(xié)議流程

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。