无密码认证
使用 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 的开源身份平台。核心协议已实现，生产环境加固仍在进行。