無密碼認證
使用 WebAuthn 通行金鑰或電子郵件傳送的 6 位驗證碼登入。尚未擁有通行金鑰的使用者也有無密碼登入的替代方式。
AUTHRIM
身分與存取管理
在邊緣網路 連接每一處。
面向 Cloudflare Workers 的開源身分與存取管理平台，已獲 OpenID Certified™ 認證。以邊緣架構提供身分認證、授權和身分聯盟。
面向 Cloudflare Workers 的開源身分與存取管理平台，已獲 OpenID Certified™ 認證。以邊緣架構提供身分認證、授權和身分聯盟。
尚未到 1.0 版本。 核心通訊協定已實作，正式環境的強化與驗證仍在進行。
使用 WebAuthn 通行金鑰或電子郵件傳送的 6 位驗證碼登入。尚未擁有通行金鑰的使用者也有無密碼登入的替代方式。
透過 OpenID Connect 和 SAML 2.0 連接應用程式與現有身分提供方。支援首次登入時建立帳戶，以及關聯外部身分。
基於角色（RBAC）、屬性（ABAC）和關係（ReBAC）控制存取。透過 API 檢查權限，各租戶分別管理策略。
隨著使用者成長自動擴展 Cloudflare D1 容量。預測需求並增加資料庫分片，讓成長不必以更換平台為前提。
產品筆記
分開儲存個人資料，協助故障排查與帳戶刪除。
產品筆記
調查登入問題時，卻看到了不需要查看的個人資料。這項設計的起點，是日常維運中這種令人不安的經驗。
營運身分平台時，經常會收到這樣的回報：“有個使用者無法登入。”為了查明原因，工作人員需要進入客戶環境，找到對應帳戶。
真正需要瞭解的事情很具體：帳戶是否被鎖定？上次嘗試在什麼時間、哪個環節失敗？使用者走了哪條登入路徑？通行金鑰的註冊是否仍然有效？
這些問題都不需要知道使用者是誰。但打開帳戶後，姓名、電子郵件、電話號碼和關聯帳戶會同時出現。原本只想查看運作狀態，卻連個人身分也一並看到了。
資訊已經顯示在頁面上時，
“請不要看”並不能成為有效的保護措施。
這並不是誰違反了規定。客戶提出請求，工作人員按流程操作，卻依然看到了不需要的資訊。問題來自系統本身的結構。
如果只靠規則和培訓來解決，就會依賴每個人的記憶與自覺。Authrim將個人資料放入獨立資料庫，正是為了從結構上解決這個日常維運問題。
可直接識別個人的資訊存放在物理上獨立的資料庫中。這不是事後補上的隔離，而是在資料存取層就已經分開。
這樣就能處理開頭的問題。鎖定狀態、登入失敗記錄、裝置資訊，都可以在左側查看。授予排查所需權限時，不必同時授予右側權限，工作人員也不用刻意避開個人資料。
同樣的結構也便於回答稽核問題。姓名和電子郵件存放在哪裡、刪除涉及哪些範圍，都可以清楚說明。先解決維運問題，再獲得清晰說明系統的能力。
需要明確的是：這種分離不是法律意義上的個人資料與非個人資料的界線。
Core DB也包含IP地址、裝置資訊、工作階段歷史、認證事件、憑證中繼資料和穩定的內部使用者ID。根據具體情境，它們也可能屬於個人資料。單獨看未必能識別人，與其他資訊結合後則可能做到。
Authrim實際區分的是可直接識別個人的資料和維運所需的身分資料。目標是讓排查能夠只存取後者，而不是說後者不需要保護。
因此，不能說“個人資料只存在於PII DB”。準確的說法是：姓名、電子郵件等直接標識資訊被隔離在PII DB中，可以在不存取該儲存的情況下授予排查權限。
“請刪除我的帳戶”本身容易執行。隨後出現的兩個要求更難處理。
一是證明已經刪除，以後仍能查到何時、由誰、為何刪除。二是在一定期限內阻止重新註冊。
矛盾在於，這兩個要求都需要識別一個已經刪除的人。如果仍保留可直接識別其身分的資訊，就與刪除的目的相衝突。
實作中明確了這一取捨：只保留防止重複所需的指紋，期限過後自動刪除，同時記錄刪除時間、執行者和原因。
補充一點技術細節：電子郵件地址的熵較低。如果只是普通雜湊，字典攻擊可能找回原始地址。“無法恢復”並非無條件成立。
Authrim使用帶秘密金鑰的HMAC-SHA256盲索引，並記錄金鑰代次以支援輪換。不掌握金鑰，就無法透過重新計算指紋來驗證候選地址。
因此，金鑰隔離是這種保護的前提。如果金鑰與指紋放在一起，這項保證就不再成立。
回到“無法登入”的回報。工作人員需要找出認證停在哪個環節，通常並不需要打開姓名或電話號碼。
Authrim將直接標識資訊分開存放，讓排查權限不必包含這部分儲存。如果調查確實需要個人資料，則由具備相應額外權限的人員處理。
加密與存取控制保護資料，稽核日誌記錄使用過程。同時，工作人員應當能夠在不打開無關個人資料的情況下完成日常排查。分離儲存，就是為了讓這種狀態成為日常維運的起點。
實作狀態：已完成儲存與存取邊界的分離。
驗證：透過原始碼儲存庫中的自動化測試持續確認。
維運成熟度：仍在加強中。Authrim目前處於pre-1.0階段。
這種設計讓刪除流程更容易執行，但本身不等於符合法律要求。實際法規遵循性還取決於組織的流程與合同。
為什麼 OP 與 RP 兩端的登出認證都很重要。
產品筆記
使用者只登入一次，背後卻可能建立多個工作階段。登出時，需要確認哪些工作階段應該結束，以及通知應該傳遞到哪裡。
假設服務接入了“使用Google登入”。對使用者而言，只是點擊了一次按鈕。
但在內部，路徑上的每個系統都會建立並保存自己的工作階段。Google一份，Authrim一份，自家應用程式一份，共三份。
只要某處的工作階段仍然有效，使用者就可能繼續操作，或不輸入密碼就再次登入。
登出不只是顯示“已登出”。
需要先確定登出的範圍，再結束該範圍內的工作階段。
這裡的“鑰匙”指工作階段。存取權杖和更新權杖採用不同的機制，結束工作階段並不一定會使已簽發的權杖失效。撤銷權杖需要另行處理。
在OIDC中，工作階段登出、權杖撤銷、上游帳戶停用是三種不同操作。本文只討論工作階段。權杖何時失效，請參閱權杖內省與撤銷。
在這條連接中，上游身分提供商提供登入，應用請求登入。Authrim面向不同方向時，承擔的角色也會變化。
登入沿著路徑完成，而登出必須有人主動傳遞。
結束上游工作階段，不會自動刪除Authrim和應用程式中的工作階段。需要把結束請求傳到下游，再由各接收方結束對應工作階段。下圖展示的是所需通知方式和設定均已就緒時的連線。
| 場景 | 傳遞中斷的後果 |
|---|---|
| 離職處理 | 人事部門撤銷存取權限後，筆記型電腦上的應用仍然打開，內部資料直到第二天早上仍可見。 |
| 共用終端 | 在零售、醫院或呼叫中心，前一位使用者已登出，另一個分頁卻仍顯示其管理介面。 |
| 裝置丟失 | 點擊了‘登出所有裝置’，實際卻只結束了目前工作階段。 |
| 事件回應 | 封禁了受入侵的帳戶，攻擊者的工作階段卻仍持續到過期。 |
| 稽核 | ‘請證明登出會傳遞到所有系統。’卻拿不出證據。 |
不是沒有登出按鈕，介面也確實發生變化。問題在於生效範圍比預想的小，因此不容易發現。
通知下游主要有兩種方式，其中依賴瀏覽器的方式會遇到更多限制。
Authrim的認證覆蓋接收後通道通知的能力。接收和向下游傳送需要分別驗證。
Authrim對上游是依賴方（RP），對應用程式是OpenID提供方（OP）。要繼續傳遞登出通知，兩種角色都必須遵循規範。
OP與RP的登出協定規範（profile）認證，為這兩種角色提供驗證依據。這裡的profile指一組特定的協定要求，不是設定檔。Authrim透過OpenID Foundation的自我認證流程，使用官方一致性測試，取得了兩側的登出協定規範認證。
認證表示提交版本通過了所申請協定規範的一致性測試。它不保證客戶網路及所有關聯應用程式中的工作階段都會立即結束。
上游和各應用程式必須支援所需方式，並設定通知端點與工作階段對應關係。停用上游帳戶不一定會觸發登出通知。還應在實際部署中驗證通知失敗、重試及失敗可見性。
認證版本與協定規範見OpenID Foundation的Certified OpenID Relying Parties & Logout Profiles列表。認證範圍見認證制度說明。
登出之後，哪裡還保留著登入狀態？
交接共用終端或終止離職員工存取時，需要確認的就是這個範圍。Authrim接收並轉發通知，連接上游與應用程式的工作階段結束處理。認證是實作的驗證依據，而關聯環境中的測試用於確認實際生效範圍。
不保存密碼，整合現有的 LDAP 與 AD。
產品筆記
密碼已經保存在企業的 Active Directory 中。如何在不複製密碼雜湊、也不開放新的外部連入端點的情況下，加入現代登入方式？Authrim Relay 就是為此設計的。
員工帳戶保存在Active Directory中。密碼策略、有效期和離職停用，也一直由它管理。這套系統已經運作多年。
現在想加入通行金鑰、整理多因素認證、為更多SaaS提供SSO。目標明確，但第一步總會遇到同一個問題：在哪裡驗證密碼？
有些方案把密碼雜湊同步到雲端，有些則請內部目錄驗證。選擇時需要確認憑證放在哪裡、由哪一側建立連接，以及誰負責維護這條路徑。
WordWarden讓LDAP/AD繼續負責驗證，同時提供連接路徑選擇。對於不想公開新入站端點的組織，Authrim Relay使用出站連接。
Authrim WordWarden是一個目錄連接器。它是部署在LDAP/AD附近的小服務，接收使用者名稱和密碼，向目錄查詢，再回傳驗證結果。
登入介面、工作階段、通行金鑰、電子郵件驗證碼、對應用程式提供的身分聯盟服務、稽核關聯和身分映射由Authrim管理。WordWarden只在目錄附近執行驗證。
連接方向不同，需要設定和維護的網路元件也不同。
WordWarden有三種連接方式，區別在於組織網路是否需要公開入站端點。
如果新部署不希望增加入站存取，可以先考慮Relay。已有的公開基礎設施或隧道也有利用價值。以下是選擇方案的例子，並非實際客戶部署案例。
例如，總部執行AD、公開新伺服器需要額外審核的企業；或者不允許外部連接校園LDAP網路的大學。WordWarden主動連接Authrim，無需在內部網路新增公開入站連接埠。
不需要新公開端點，也不需要獨立隧道程序。前提是允許WebSocket出站通信，並繼續監控WordWarden及其連接。如果網路禁止一切外部通信，Relay也無法使用。
如果組織已經透過Cloudflare Tunnel發佈內部工具，並有團隊負責cloudflared更新和路由，可以把WordWarden納入同樣的流程，無需新增入站連接埠。
需要設定讓Authrim請求到達連接器的主機名稱與路徑，並維護隧道。內部主機不直接接收入站連接，但請求會經由Cloudflare的路徑到達。
企業、大學或研究機構可能已有負責DMZ和反向代理的團隊。為Authrim提供可存取的HTTPS端點，就能沿用現有憑證管理、存取日誌和監控流程。
無需維持額外的隧道或Relay連接。相應地，組織需要允許入站路徑，並負責公開端點的保護與維護。公開的是連接器的HTTPS介面，不是把LDAP/AD連接埠直接暴露到網際網路。
無論哪種方式，都要在能夠存取LDAP/AD的位置執行WordWarden。並不是學術機構就必須選某一種，而是根據現有基礎設施和網路策略來選擇。
Relay模式下，WordWarden從組織內部透過WebSocket連接Authrim。WebSocket會保持通信路徑，讓雙方都能通過它傳送訊息。
WordWarden保持連接並等待。有人登入時，Authrim透過同一路徑發出“請驗證這個使用者”的請求，WordWarden查詢內部目錄，再回傳結果。
這就像從組織內部撥出電話後保持通話，對方也可以開口說話。每次請求都不需要從外部重新連接內部網路。
這樣，目錄所在網路不必為此公開URL，也減少了新公開主機名稱、憑證和WAF的管理。仍需允許出站連接、維護WordWarden並監控連接狀態。
區別在於由誰首先建立連接。Direct HTTPS需要組織提供Authrim可存取的端點；Relay則由內部WordWarden向Authrim建立加密WebSocket連接（wss）。
常見的有狀態防火牆或NAT會追蹤內部發起的連接，並允許該連接的回傳流量。因此，WordWarden無需公開接收外部新連接的連接埠，也無需設定連接埠轉發，就能收到驗證請求。
這並不意味著通信不使用連接埠。通常wss使用目標端的TCP 443連接埠。防火牆或代理需要允許到Relay的出站存取和持續WebSocket連接。斷線期間無法透過該路徑接收請求，因此也需要監控。
減少外部新連接入口，不代表已建立的路徑不會收到驗證請求。仍然需要認證通信方，並驗證收到的請求。
出站連接也需要認證對方。Relay同時檢查連接器身分與設定的目標。
WordWarden對短期挑戰回傳HMAC回應，對包含挑戰ID和nonce的字串簽名，並檢查目標URL中的租戶ID和連接器ID是否與自身設定一致。
三種連接方式都必須使用HMAC。Relay減少的是入站暴露面，並不能省略連接器認證或秘密資訊管理。
這一點需要說清楚：並不是“密碼不會離開內部網路”。
使用者在登入介面輸入密碼後，密碼會經過Authrim。準確的表述是“Authrim與WordWarden不保存密碼”，而不是“密碼不會離開組織”。
驗證成功後，Authrim得到結果，以及請求屬性中連接器本地允許列表准許的部分。不是請求方決定能取什麼，而是目錄一側決定傳出什麼。
因此，僅修改Authrim一側的設定，無法擴大從內部網路獲取的屬性範圍。
這種連接是為了逐步遷移。
LDAP/AD繼續作為密碼權威來源，使用者仍使用原有帳戶登入，同時逐步註冊通行金鑰。電子郵件驗證碼作為恢復路徑保留，讓認證方式轉換時登入仍可繼續。
文件也明確禁止把LDAP/AD密碼雜湊匯出到Authrim。那樣做會把遷移橋梁變成憑證副本。
正在準備公開測試版。首個目標版本是v0.1.0-beta.1。
適合試點使用，面向能夠在LDAP/AD附近運作小服務，並理解目錄、網路、TLS和秘密管理邊界的組織。這不是代管目錄服務。
需要Authrim 0.3.2或更高版本，並啟用Directory Authentication與Relay。目前測試版修改設定後需要重新啟動程序。
複製憑證或開放入站連接，
並非僅有的選擇。
在目錄附近驗證，並由內部建立出站連接，就能在不複製密碼雜湊、不公開內部入站端點的情況下接入現代登入。
最終希望走向的是通行金鑰遷移。目錄連接提供了基礎，讓遷移可以在不打斷使用者登入的情況下進行。
不遷移現有帳戶，增加 D1 分片。
產品筆記
使用者越來越多，是件好事。但現有資料庫還能支撐多久，也逐漸成為問題。Authrim 會在需要之前為新帳戶準備好儲存空間，讓服務成長不必從資料搬遷開始。
Authrim使用的Cloudflare D1對單個資料庫有容量上限：免費方案500 MB，付費方案10 GB。隨著使用者和資料成長，最終會需要新的存放位置。
Authrim從一開始就支援把帳戶分配到多個資料庫，因此擴容時不必搬遷所有已有帳戶。這裡把每個儲存單元稱為分片（shard）。
已有帳戶留在原處，為新帳戶增加存放位置。這就是帳戶儲存擴展的基本方式。
租戶設定（例如OAuth客戶端和策略）、帳戶與個人資料、透過電子郵件查找帳戶位置的索引，在Authrim中分別儲存。
使用者增加不代表所有資料庫都要一起擴容。帳戶儲存與查找索引的記錄數量和成長速度不同，只需為有需要的部分增加容量。
新帳戶會被分配到租戶可用的分片。系統優先選擇運作正常、已分配數量相對目標數量較低的分片。
判斷依據不是磁碟使用率，而是距離設定的目標帳戶數還剩多少名額。例如目標為10萬帳戶時，剩餘2萬的餘量可以作為準備下一處儲存的參考。
可用分片餘量較小時，系統會分配已準備好的備用分片。多個租戶共用的共享型，以及一個租戶獨享的專用型，都採用這一思路。
共享租戶
專用租戶
共享與專用混合
設定自動佈建後，註冊量每次成長時，工作人員不必再手動建立資料庫、準備表結構並連接新註冊位置。每次增加容量，也不必為已有帳戶制定搬遷計劃。
工作人員主要確認擴容進度、失敗情況，以及使用量和費用是否符合預期。權限不足或服務上限仍需人工處理。在這種分工下，Authrim負責準備下一個存放位置。
同樣剩餘2萬個名額，每天新增100個帳戶和每小時新增1萬個帳戶，準備時間完全不同。
Authrim結合目前分配數量與近期註冊速度，預測帳戶儲存和查找索引的容量需求。排程工作每分鐘執行，分配帳戶後也會更新帳戶預測。
計算需求時，會計入正在建立的分片，避免多個流程發現同一次容量不足後，各自重複建立資料庫。
備用分片不足時，Authrim透過Cloudflare管理API建立D1，準備表結構、設定Worker存取並分發儲存位置。讀寫檢查通過後，才把資料庫投入分配。
自動執行需要啟用自動佈建，並分別設定D1與Workers的API權杖。無法自動執行時，工作人員可通過設定工具繼續操作。
建立進度會被保存。暫時通訊故障可以從該狀態重試；權限不足或資源上限則需要先解決原因，再繼續執行。
如果準備速度跟不上、註冊名額耗盡，新註冊可能需要重試。提前準備的目的就是減少這種等待。
增加容量與移動已有資料是不同操作。例如，把租戶從共享分片遷往專用分片，不僅要新增位置，還要複製已有資料。
維運人員決定是否開始遷移。批准後，由Authrim執行同步、驗證與切換。
目前支援的佈局變更是共享轉專用。尚未實作專用轉共享，也不會自動把已有帳戶重新均勻分布。
刪除退役分片同樣需要人工批准。容量成長不會自動觸發已有資料的移動或刪除。
2026年7月使用20萬個測試帳戶測量時，Core約208 MB，PII約238 MB，Lookup約426 MB，分別不到付費方案單庫10 GB上限的5%。實際用量取決於儲存的屬性與索引。
每個分片的預設目標是10萬帳戶。系統保留準備下一個分片的餘量，而不是盡量填滿物理容量。
Authrim仍處於pre-1.0階段，長期、大規模正式環境的維運經驗還有待積累。20萬個測試帳戶的容量測量，不等同於數百萬人每天使用的正式環境實績。
小型服務不需要一開始就準備大型部署。可以從少量分片開始，隨著註冊成長增加位置。Authrim把所需準備和流程納入系統。
使用者開始成長時，不必先把資料庫搬遷列為首要任務。減少這些工作，才能把更多時間投入服務本身。
測量時間為2026年7月30日，使用20萬個測試帳戶。MB採用十進制單位。D1容量上限見Cloudflare文件。
K6 Cloud 測試覆蓋有代表性的 OIDC 工作負載。容量取決於負載模式、Cloudflare 方案限制、儲存及分片方式。
測試報告 →Authrim 不按使用者收費。基礎設施費用取決於請求量、CPU 時間、儲存和日誌。這裡僅供粗略估算 Cloudflare 費用，並非正式環境報價。
採用 Cloudflare Workers 的價格，並根據觀察到的 Authrim 使用情況，為 KV、Durable Objects 和 D1 計入費用系數。
說明 — 僅含基礎設施。不含法規遵循、監控、支援、維運、安全審查、外部資料庫及大量 R2 或歸檔用量。實際費用因部署方式而異。
以 TypeScript 為中心的 API、JavaScript SDK，以及用於評估和開發邊緣身分服務的安裝流程。
自行託管帶來控制權，支援 SAML、SCIM、稽核日誌、租戶隔離和儲存及日誌控制。正式環境強化仍在進行。
在 Cloudflare 上起步，無需支付按使用者計費的 Authrim 費用，再根據實測的請求量、CPU、儲存和日誌用量擴展。
OpenID 認證
Authrim v0.4.0
7 個類別 · 共 28 項協定規範
點選類別名稱可查看官方認證清單。
Basic OP · Implicit OP · Hybrid OP · Config OP · Dynamic OP · Form Post OP · 3rd Party-Init OP
RP-Initiated OP · Session OP · Front-Channel OP · Back-Channel OP
Basic RP · Config RP · Dynamic RP · Form Post RP
RP-Initiated RP · Back-Channel RP
Security Profile: private key + DPoP · OpenID Connect · Message Signing: JAR · Message Signing: JARM · Client Credentials: private key + DPoP
Security Profile: private key + DPoP · OpenID Connect · Message Signing: JAR · Message Signing: JARM
Poll: Private Key · Ping: Private Key
試用面向 Cloudflare Workers 的開源身分平台。核心通訊協定已實作，正式環境強化仍在進行。