ERC：OAWE - 以太坊 OAuth 協議

---

eip: TBD

標題：OAWE - 以太坊 OAuth (OAuth With Ethereum)

描述：一種使用以太坊帳戶的無許可 OAuth 2.0 客戶端身份驗證協定。

作者：Zainan Victor Zhou (@xinbenlv>)

狀態：草案 (Draft)

類型：標準軌跡 (Standards Track)

類別：ERC

創建日期：2026-03-11

要求：191, 712

摘要

以太坊 OAuth (OAWE) 為無許可的 OAuth 2.0 客戶端身份驗證提供了一項標準。它允許開發者使用以太坊地址或 ENS 名稱作為其 OAuth client_id，從而繞過中心化的應用程式註冊門戶。透過利用現有的 OAuth 2.0 擴展（RFC 9101 和 RFC 7523），開發者可以使用其以太坊私鑰動態簽署授權請求和令牌交換，在無需靜態 client_secret 的情況下證明所有權和意圖。

動機

傳統的 OAuth 2.0 要求開發者在中心化平台註冊應用程式，以獲取 client_id、client_secret 並將 redirect_uris 列入白名單。這引入了巨大的摩擦，產生了圍繞密鑰管理的漏洞，並依賴於中心化的門控機制。

雖然各種技術和學術提案都試圖橋接去中心化密碼學與 OAuth，但在「無許可客戶端註冊」方面仍存在關鍵空白：

• 以太坊登入 (EIP-4361)： SIWE 成功地實現了「資源所有者」（使用者）身份驗證階段的去中心化。然而，它仍讓「客戶端」（開發者）依賴傳統的中心化註冊門戶，以獲取啟動 SIWE 流程所需的憑證。

• RFC 7523 (私鑰 JWTs)： 現有的 OAuth 標準確實支持非對稱金鑰身份驗證以取代靜態 client_secret。然而，這仍然需要一個有許可的註冊步驟，開發者必須手動將其公鑰或 JWKS URI 上傳到平台的後端以獲得批准。

• 基於 DID 和 SSI 的 OAuth： 許多學術和 W3C 提案（例如 OAuth 中的去中心化識別碼）試圖將整個授權伺服器去中心化。這需要大規模的基礎設施改造並破壞了向後相容性，嚴重限制了主流 Web2 平台的採用。

• Web3 原生 API 身份驗證： 許多去中心化應用程式利用臨時的 EIP-712 簽名作為後端 API 金鑰。然而，這些是孤立的、專有的實現，無法與全球通用的標準化 OAuth 2.0 授權碼流程整合。

OAWE 解決了這一特定空白。透過將標準以太坊帳戶密碼學與現有的、未經修改的 OAuth 2.0 擴展（用於前向通道的 RFC 9101 和用於後向通道的 RFC 7523）相結合，OAWE 實現了完全無許可的動態客戶端註冊流程。開發者可以立即整合 API，而授權伺服器可以動態驗證客戶端身份和回調路由，無需事先註冊，同時保持嚴格的密碼學安全性和最大的向後相容性。

規範

OAWE 協定利用標準的 OAuth 2.0 基礎設施，僅修改客戶端身份驗證機制。

1. 客戶端識別

OAuth client_id 必須是一個有效的以太坊地址，或是一個解析為以太坊地址的經過驗證的 ENS 名稱。

2. 第一階段：授權請求（前向通道）

客戶端不得將授權參數（如 redirect_uri）作為純查詢字串傳遞。相反，客戶端必須使用 RFC 9101 中定義的 JWT 安全授權請求 (JAR)。

• 客戶端構建一個包含標準 OAuth 參數（response_type、client_id、redirect_uri、scope、state、nonce）的 EIP-712 類型化數據負載。

• 該負載由與 client_id 關聯的以太坊私鑰簽署。

• 授權伺服器在顯示使用者同意介面之前，根據 client_id 驗證簽名，動態信任所提供的 redirect_uri。

3. 第二階段：令牌交換（後向通道）

為了將授權碼交換為存取令牌 (Access Token)，客戶端必須使用 RFC 7523 中定義的 JSON Web Token (JWT) 進行身份驗證，以取代傳統的 client_secret。

• 客戶端構建一個由與 client_id 關聯的以太坊私鑰簽署的 JWT 斷言 (assertion)。

• 授權伺服器在核發存取令牌前驗證簽名。

向後相容性

OAWE 與現有的 OAuth 2.0 部署完全向後相容。它完全依賴於已建立的 IETF 標準（RFC 9101 和 RFC 7523）。平台只需實作 secp256k1 簽名驗證，即可在支持傳統靜態客戶端的同時支持 OAWE 客戶端。

安全考量

• 網路釣魚與欺騙： 由於任何開發者都可以立即生成以太坊地址，授權伺服器應將原始 OAWE 地址視為「未驗證」並向使用者顯示警告。聲譽可以透過 ENS、鏈上質押或可驗證憑證來建立。

• 女巫攻擊與速率限制： 惡意行為者可以生成無限數量的地址來繞過 API 配額。平台可以實作 Web3 原生的抗女巫攻擊機制，例如要求 client_id 持有最低 ETH 餘額或特定的證明 (attestation)。

        1 則貼文 - 1 位參與者
  
        [閱讀完整主題](https://ethereum-magicians.org/t/erc-oawe-oauth-with-ethereum/27963)