我正在使用帶有環回介面重定向的 OAuth 本機應用程式，并嘗試將 RFC6749（OAuth 2.0 授權框架）與 RFC8252（本機應用程式的 OAuth 2.0）協調起來：
在 RFC6749 中，規范要求使用絕對 URI 作為客戶端的重定向端點（第3.1.2節）：
重定向端點 URI 必須是一個絕對 URI ... 端點 URI 不能包括片段組件。
但是，這在 RFC8252 中似乎有一個例外。規范規定任何埠都可以用于環回 IP 重定向 URI（第7.3節）：
授權服務器必須允許在請求環回 IP 重定向 URI 時指定任何埠，以適應在請求時從作業系統獲取可用臨時埠的客戶端。
并表示將支持環回 IP 重定向 URI（附錄 A.）：
支持本機應用程式的 OAuth 服務器必須：...
- 支持環回 IP 重定向 URI。這是支持桌面作業系統所必需的。
RFC8252 還提供了注冊說明（第8.4節）：
授權服務器必須要求客戶端注冊其完整的重定向 URI（包括路徑組件）并拒絕指定的重定向 URI 與注冊的 URI 不完全匹配的授權請求；例外是環回重定向，除了埠 URI 組件外，需要完全匹配。
因此，我了解具有本機應用程式客戶端的 OAuth 2.0 授權服務器的正確行為是：
- 需要注冊環回重定向 URI（即
http://127.0.0.1/oauth2redirect/example-provider），可能帶有通配符埠:* - 在 GET 請求上
/authorize，將redirect_uri請求引數與注冊的 URI匹配，但允許指定任何埠（即，http://127.0.0.1:61023/oauth2redirect/example-provider將被接受）
我在這里錯過了什么嗎？這是具有注冊本機應用程式的 OAuth 2.0 授權服務器的預期行為嗎？
uj5u.com熱心網友回復：
對于桌面應用程式，通常的做法是在運行時找到一個空閑埠，然后在沒有任何路徑的 URL（例如 http://localhost:8000）上啟動環回服務器。此偵聽器僅存在一個原因，即接收登錄回應。
理論上，您可以注冊http://localhost為客戶端的重定向 URI，任何埠都可以使用，盡管我很少看到授權服務器支持的埠。
這是我的一些示例代碼，用于展示它的外觀。因此，我的應用程式為埠 8001-8003 注冊了三個特定的重定向 URL。
您是正確的，應該只注冊確切的 URL，以避免開放重定向器漏洞。桌面應用程式和多個埠的 RFC8252 行為是一種特殊情況。您可以選擇使用它，也可以使用不同的埠注冊多個重定向 URI。
另一種選擇是對桌面應用程式使用私有 URI 方案（我個人更喜歡這個）。移動應用程式應使用 HTTPS 重定向 URI，作為最安全的選項 - 這是金融級應用程式所必需的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/316610.html