OAuth 2.0 和 OAuth 2.1比較：
OAuth 2.0 和 OAuth 2.1 是授權框架的不同版本，它們用于允許應用程序安全地訪問用戶在另一個服務上的數據。以下是它們之間的一些主要區別：
- 安全性增強：OAuth 2.1 旨在提高安全性，它整合了自 OAuth 2.0 發布以來的最佳實踐。它特別關注更好的默認安全性，并且不包含任何被認為是實驗性的或仍在進行中的特性。
- 移除不安全的授權類型：在 OAuth 2.1 中，一些被認為是不安全的授權類型被移除，例如隱式授權（"response_type=token"）和資源所有者密碼憑據授權。
- PKCE（Proof Key for Code Exchange）要求：OAuth 2.1 要求在授權代碼授予時使用 PKCE，以增強移動應用和本地應用的安全性。
- 重定向 URI 的嚴格匹配：OAuth 2.1 要求使用精確字符串匹配來比較重定向 URI，而不是使用通配符或子字符串匹配。
- 持有者令牌的使用：在 OAuth 2.1 中，持有者令牌（訪問令牌）不再通過 URI 查詢字符串傳輸，以減少泄露的風險。
- 刷新令牌的保護：OAuth 2.1 要求刷新令牌必須受發件人限制或一次性使用，以增強刷新令牌的安全性。
- 規范的整合和精簡：OAuth 2.1 根據安全最佳實踐對 OAuth 2.0 協議進行整合和精簡，移除了不安全的授權流程。
- 向后兼容性：盡管 OAuth 2.1 旨在提高安全性，但它并不是 OAuth 2.0 的完全重構，而是一個改進的版本。OAuth 2.1 建立在 OAuth 2.0 RFC 的基礎上，繼承了所有未明確省略或更改的行為。
- 實施狀態：截至知識更新日期，OAuth 2.1 規范仍在討論中，并沒有最終確定。開發者可以遵循安全性最佳實踐為 OAuth 2.1 的發布做好準備，但目前還不能使用正式的 OAuth 2.1 規范。
這些變化意味著 OAuth 2.1 將更加注重安全性和最佳實踐的實施，同時保持與 OAuth 2.0 的兼容性，以便開發者可以平滑過渡到新版本。
OAuth 2.1
相關網址：
OAuth 2.1
It's Time for OAuth 2.1 ? Aaron Parecki
OAuth 2.1: How Many RFCs Does it Take to Change a Lightbulb? | Okta Developer
OAuth 2.1 是 OAuth 2.0 的進化版，它旨在簡化 OAuth 2.0 的實現，同時增強安全性。OAuth 2.1 整合了 OAuth 2.0 中的一些最佳實踐和擴展，以提供一個更加安全且易于實施的框架。以下是學習 OAuth 2.1 的一些關鍵點：
1. OAuth 2.1 的核心組件
-
授權服務器（Authorization Server）：負責驗證資源擁有者的身份，并頒發訪問令牌。
-
資源服務器（Resource Server）：托管受保護的資源，能夠使用訪問令牌驗證請求。
-
資源擁有者（Resource Owner）：通常是用戶，擁有對受保護資源訪問權限的實體。
-
客戶端（Client）：代表資源擁有者并獲得授權后訪問受保護資源的軟件應用。
-
訪問令牌（Access Token）：授予客戶端訪問受保護資源的憑證。
2. OAuth 2.1 的授權流程
OAuth 2.1 定義了幾種授權流程，包括：
-
授權碼模式（Authorization Code Grant）：這是最常用且安全性較高的流程，適用于有后端的應用程序。它涉及到一個前端重定向的過程，用戶同意授權后，客戶端通過后端服務器交換授權碼以獲取訪問令牌（access token）。
-
客戶端憑據模式（Client Credentials Grant）：適用于沒有前端的命令行應用或者服務端應用，客戶端直接使用其憑證（client ID 和 client secret）向授權服務器請求訪問令牌。
-
設備授權模式（Device Authorization Grant）：適用于在設備上運行的應用程序，這些設備可能沒有傳統的輸入機制（如智能電視、打印機等），用戶通過設備上的說明在另一設備上完成授權。
3. OAuth 2.1 的安全增強
OAuth 2.1 引入了一些安全增強措施，包括：
-
強制使用 HTTPS：確保所有通信都是加密的。
-
禁止使用明文密碼：不再推薦使用資源擁有者密碼憑證流程。
-
引入 PKCE（Proof Key for Code Exchange）：用于增強授權碼流程的安全性，防止授權碼攔截攻擊。
-
訪問令牌的生命周期管理：推薦使用短期訪問令牌和刷新令牌。
