在討論各個組件之前，讓我們先看看當(dāng)用戶發(fā)起涉及另一個不相關(guān)網(wǎng)站或服務(wù)的網(wǎng)站操作時發(fā)生的事件順序。假設(shè)用戶已使用 HTTPS 登錄到第一個網(wǎng)站。

1. 站點 A 使用 OAuth 2.0 與站點 B 連接，提供用戶的驗證身份。
2. 站點 B 發(fā)布一次性請求令牌以及唯一的密鑰。  
3. 站點 A 將令牌和秘密發(fā)送給用戶的客戶端軟件。
4. 客戶端軟件將請求令牌發(fā)送給授權(quán)提供商（OAuth 的主引擎）。 
5. 如果由于任何原因，提供商未進(jìn)行身份驗證，則要求客戶批準(zhǔn)站點 B 的身份驗證。
6. 用戶（或用戶軟件）在現(xiàn)場批準(zhǔn)特定類型的交易 A。
7. 請求令牌現(xiàn)在成為已批準(zhǔn)的訪問令牌并授予用戶。
8. 反過來，用戶將批準(zhǔn)的訪問令牌提供給站點 A。
9. 站點 A 現(xiàn)在將訪問令牌提供給站點 B。這證明了身份驗證。
10. 站點 B（最后）代表用戶允許站點 A 訪問。
11. 任務(wù)完成。

關(guān)于 OAuth 2.0 工作原理的討論很容易變得非常技術(shù)化。從高層次來看，基本構(gòu)建塊及其功能分為五個核心組件。

1. 范圍和同意
2. 參與者
3. 客戶端
4. 令牌
5. 流程

現(xiàn)在，讓我們更詳細(xì)地分解每個組件。

1. 范圍和同意

范圍是一種定義權(quán)限并為應(yīng)用程序或服務(wù)可以訪問或不能訪問的內(nèi)容設(shè)置邊界的機(jī)制。

當(dāng)應(yīng)用程序發(fā)送授權(quán)請求時，會向用戶顯示請求的具體范圍，并且用戶必須授權(quán)同意。 

此同意作為授權(quán)證明并允許授予訪問令牌。

2. 演員

OAuth 流程中出現(xiàn)四個參與者：

• 資源所有者擁有請求訪問的數(shù)據(jù)。資源所有者可以是個人最終用戶或公司?；氐轿覀兊拇筒窜囪€匙類比，您是豪華車的資源所有者。
• 資源服務(wù)器是安全存儲應(yīng)用程序或服務(wù)請求訪問的數(shù)據(jù)的 API 或服務(wù)器。資源服務(wù)器必須接受并驗證來自請求應(yīng)用程序的訪問令牌，才能授予對數(shù)據(jù)的訪問權(quán)限。在我們的比喻中，資源服務(wù)器是汽車的計算機(jī)，用于驗證代客鑰匙的有效性。
• 客戶端是請求訪問資源服務(wù)器所保護(hù)的數(shù)據(jù)的應(yīng)用程序或服務(wù)?？蛻舳送ㄟ^向資源服務(wù)器提供有效的訪問令牌來獲得對所請求資源的訪問權(quán)限。再次使用我們的類比，客戶端是請求移動汽車的代客泊車員。
• 授權(quán)服務(wù)器負(fù)責(zé)處理令牌管理，因此大多數(shù) OAuth 都發(fā)生在授權(quán)服務(wù)器。來自客戶端的訪問請求被定向到授權(quán)服務(wù)器。一旦資源所有者看到范圍并表示同意，授權(quán)服務(wù)器就會向資源服務(wù)器發(fā)出新的訪問令牌。

3. 客戶端

客戶端可以是機(jī)密的，也可以是公開的。機(jī)密客戶端顧名思義就是保守秘密。它們在安全區(qū)域運(yùn)行，最終用戶無法訪問。  

公共客戶端是安全性較低的實體，例如瀏覽器、移動應(yīng)用程序和物聯(lián)網(wǎng)設(shè)備，而機(jī)密客戶端則更安全，并且可以被授予更多對安全資源的訪問權(quán)限。

4. Token

OAuth 流中有兩種類型的令牌參與者——訪問令牌和刷新令牌。

• 訪問令牌由授權(quán)服務(wù)器授予，用于訪問資源服務(wù)器中的數(shù)據(jù)。它們通常允許客戶端訪問資源幾分鐘到幾小時。
• 刷新令牌僅授予具有安全身份驗證協(xié)議的機(jī)密客戶端，有效期為幾天、幾個月甚至幾年 – 它們還可用于為其他客戶端獲取新的訪問令牌。

當(dāng)您終止刷新令牌時，您將獲得一個新的、經(jīng)過加密簽名的訪問令牌。

通常，這些令牌采用 JavaScript 對象表示法 (JSON) 格式，稱為 JSON Web 令牌或 JWT（發(fā)音為“jots”）。JWT 允許數(shù)字簽名（也稱為聲明），稍后可以使用秘密簽名密鑰進(jìn)行驗證。

令牌從授權(quán)服務(wù)器上的兩個主要端點獲取。第一個是授予用戶同意和授權(quán)的“授權(quán)端點”。授權(quán)隨后傳遞到“令牌端點”，在此處理授權(quán)并授予刷新令牌和訪問令牌。

訪問令牌是訪問 API 的關(guān)鍵。但一旦過期，就需要使用刷新令牌再次前往令牌端點，重新執(zhí)行所有操作。

5. 流程

流程是客戶端訪問請求的資源所需的一系列步驟和授權(quán)授予類型。 

OAuth 2.0 包括六種流程，用于不同類型的交互。

• 隱式流程涉及向公共客戶端授予短期訪問令牌。
• 授權(quán)碼流程是最安全的流程，并使用授權(quán)碼授予和訪問令牌的組合。
• 客戶端憑證流旨在處理來自機(jī)密客戶端的服務(wù)器到服務(wù)器的訪問請求。
• 資源所有者密碼流程很少使用，并且在大多數(shù)情況下不推薦使用。
• 斷言流類似于客戶端憑證流，并允許使用聯(lián)合。
• 設(shè)備流處理通過電視屏幕等智能設(shè)備發(fā)出的訪問請求。

OAuth 2.0 的潛在缺點或為什么它不足以保護(hù)你的 API

盡管 OAuth 2.0 因保護(hù)私人數(shù)據(jù)而受到開發(fā)人員和最終用戶的歡迎，但也有批評者。 

一些人猛烈抨擊 1.0 版和 2.0 版之間的重大變化，這并非毫無道理。OAuth 2.0 的安全性明顯低于其前身，而且更為復(fù)雜。 

OAuth2.0最大的詬病可能就是不直接支持客戶端驗證、簽名、通道綁定。

批評者指責(zé) OAuth 2.0 的創(chuàng)建者選擇專注于提高網(wǎng)站和設(shè)備之間的互操作性，而不是提供額外的范圍和安全性。

OAuth 建議使用第三方保護(hù)協(xié)議（例如傳輸層安全性（TLS））  來提供附加功能。

雖然 OAuth 2.0 在安全使用私人數(shù)據(jù)方面向前邁了一步，但它遠(yuǎn)不足以防止您的 API 受到在OWASP API 安全性前 10 名列表中排名第一的對象級授權(quán) (BOLA) 漏洞的侵害。

公司依靠自動化 API 安全測試平臺全面測試其 API，以跟上不斷發(fā)展的安全標(biāo)準(zhǔn)。

文章來源：What Is OAuth 2.0 and How Does It Work?

#你可能也喜歡這些API文章!

什么是SQL注入？理解、風(fēng)險與防范技巧

保護(hù)數(shù)據(jù)的 10 個基本 API 安全最佳實踐

通過 API 集成優(yōu)化貨幣兌換

API 安全檢查表：您需要了解的內(nèi)容

2024年免費(fèi)的文本工具API接口清單

構(gòu)建高效API的10個API設(shè)計最佳實踐

如何找到合適的API

8個最佳Swagger替代品

探索頂級PDF水印API：PDFBlocks（2024年更新）