身份、权限与租户设计
# 身份、权限与租户设计
版本 v1.9，2026-10-28。返回总览。
# 1. 主体与边界
R1 的平台与租户主体继续隔离；M5已追加会员和独立服务身份，禁止把“平台管理员”当成普通租户的超级角色：
| 主体 | 身份存储 | 能访问的范围 |
|---|---|---|
| 租户用户 | users，归属一个 tenant_id | 当前租户已开通的功能和获授权的数据 |
| 平台运营 | platform_users | 租户、套餐、能力目录和平台审计；默认不能读取租户业务数据 |
| 会员 | member_users，归属一个 tenant_id | 独立本人会话/资料/注销，不继承后台角色 |
| 服务身份 | service_accounts，归属一个 tenant_id | 机器凭据与当前发布scope，只访问明确消费者 |
R1 不做同一业务账号同时加入多个租户；多用户类型与跨租户 membership 是不同维度。相同用户名可存在于不同租户，登录时明确提供 tenantCode。未来多租户成员身份应引入 identity + membership，不能直接让客户端任意改 tenantId。
平台路由使用 /api/platform/v1，租户后台使用 /api/admin/v1。会话有不可混用的 audience；平台用户和租户用户分别登录。R1 不提供 impersonation、visit-tenant-id 或“租户 0 免隔离”机制。需要平台代管时，单独设计有时间限制、明确目的和完整审计的授权流程。
# 2. 登录和会话
建议 R1 参数：access token 15 分钟、refresh cookie 空闲有效期 7 天、会话绝对有效期 30 天，均可配置。access token 由密码学随机数产生，至少 256 bit，数据库仅保存摘要。密码采用 bcrypt，成本通过部署环境基准确定，API 拒绝超过 bcrypt 限制的密码字节长度，不静默截断。
面向 二级等保 的口令复杂度、失败锁定、会话空闲超时、特权再鉴别与审计留存等可配置基线，在 二级等保合规要求 §4.1 中定义；与本文会话模型冲突时以 更严格 者为准，并在配置变更时写审计。
登录步骤：验证 Origin 和专用请求头 → 检查账户是否处于 locked_until → 按租户/账号/IP 限流 → 查询租户及用户状态 → 验证密码 → 建立会话和 token → 写安全审计 → 返回 accessToken 并设置刷新 cookie。失败统一为“账号或密码错误”，包括未知租户、未知账号和错误密码，避免提供细粒度枚举信息。
# 2.1 登录失败：限流与账户锁定
两层机制并存，审计事件须区分 action（或等价 reason），不能混为一条“登录失败”：
| 机制 | 目的 | 行为 |
|---|---|---|
| IP / 租户+账号限流 | 防撞库、降低分布式尝试速率 | 超阈值短期拒绝（如 HTTP 429），不递增用户 failed_login_count |
| 账户锁定 | 等保“失败处理” | 同一用户连续口令错误达策略阈值（默认 5 次）→ 写 locked_until（默认 15 分钟）→ 登录与刷新均拒绝；成功登录清零失败计数；安全管理员可 unlock（须权限与审计） |
锁定期间对外仍返回与口令错误一致的提示，避免向攻击者暴露锁定状态；运维与安全审计日志须记录锁定/解锁与来源 IP。
# 2.2 会话空闲与 refresh cookie
| 维度 | 默认 | 说明 |
|---|---|---|
| access token | 15 分钟 | 每次 API 校验会话与 idle_expires_at |
| refresh cookie 空闲 | 7 天 | 仅表示浏览器可携带 refresh 凭证的上限；不延长业务 idle |
| 会话绝对有效期 | 30 天 | absolute_expires_at，刷新不突破 |
| 业务 idle（等保基线） | 30 分钟 | 受保护请求与成功 refresh 更新 last_seen_at 并重算 idle_expires_at；idle 已过期则拒绝 refresh 并撤销或要求重新登录，即使 cookie 仍在 7 天内 |
强制改密受限会话的 30 分钟绝对上限与 idle 规则独立；改密成功仍撤销全部会话。
刷新 cookie 无 Domain，租户 Path 为 /api/admin/v1/auth，平台 Path 为 /api/platform/v1/auth。名称和属性按显式环境 profile 成对配置：
| profile | 租户 / 平台 cookie 名 | 属性与约束 |
|---|---|---|
| production 或本地 HTTPS | __Secure-admin_rt / __Secure-platform_rt | Secure; HttpOnly; SameSite=Strict，通过 HTTPS 设置 |
| development-http | dev_admin_rt / dev_platform_rt | HttpOnly; SameSite=Strict，不带 Secure；仅允许显式开发配置和本地回环 Origin |
__Secure- 名称始终要求 Secure 属性；HTTP不能只去掉属性而沿用该名称。按2026-10-23已实施的传输规则，生产未使用HTTPS时只在启动写WARN，不拒绝启动；生产JSON内容仍强制JWE。刷新Cookie名称与Secure按可信Origin协议选择：HTTPS用__Secure-，HTTP用dev_，profile参与启动校验及告警，不信任任意代理头。写请求只读取本次可信Origin对应的Cookie；无Origin的内部兼容读取按已登记名称顺序取首个非空凭据，外部刷新/退出写路由仍必须先通过Origin校验。退出按名称、Path及相应Secure方式清除当前和历史Cookie，不能因profile切换留下可恢复凭据。依据见 Cookie 前缀规则 (opens new window)。
M2 已接入平台默认与租户 inherit/custom 安全策略。默认口令有效期 90 天；0 天明确关闭自然过期，不能解除已经生效的强制改密。正确口令到期进入同一受限改密流程，已有 access/refresh 也必须转为受限，撤销其他旧会话并审计；受限绝对期限最多 30 分钟，刷新不可续长。缺失或未来改密时间按需要改密处理，不伪造当前时间回填。
access token 仅在前端内存保存；页面刷新先调用刷新端点恢复。需修改 Vben access store 的默认持久化策略，移除 accessToken、refreshToken 和权限码持久化，并清理旧版本残留。权限码重新从服务端加载；锁屏状态不是服务端身份认证。
login/refresh/logout 均要求可信 Origin、Content-Type: application/json 和 X-App-Request: admin（平台使用 platform）；服务端精确匹配 Origin，不允许任意带凭证 CORS。跨站表单不满足 JSON 和专用头，跨站脚本的预检不获授权。Referer 不作为放宽 Origin 的兜底。生产同域部署，独立域名部署必须重新评审 cookie 和 CSRF 策略。
# 强制改密受限会话
初始账号或重置密码后需要改密时，登录及刷新响应均返回 mustChangePassword: true。服务端把该会话限制为 change_password_only：只允许 POST /auth/refresh、POST /auth/logout 和 PUT /profile/password；me/codes/menus 及其他受保护 API 返回 HTTP 403 + code 403003。刷新只恢复同一受限身份，不解除改密限制；受限会话绝对有效期默认 30 分钟，刷新不延长该上限。
前端在收到登录/刷新结果后先检查标志，清空旧权限和动态路由，直接进入固定的改密页，不请求 me/codes/menus。页面重载时允许刷新恢复受限状态；刷新凭证失效则回登录页。改密接口从 Actor 取目标用户，校验 currentPassword、新密码策略并拒绝沿用旧密码；成功时清除 must_change_password、递增 password_version、撤销用户全部会话并清除刷新 cookie，返回成功后前端回登录页重新认证。普通登录初始化仅在标志为 false 时执行，详见 前端启动合同。
# 3. 刷新、撤销与故障
刷新令牌每次使用在业务数据库事务内锁定并轮换，旧摘要记录保留到会话绝对到期，以识别重放。重复使用已消费令牌撤销该会话及其全部 access token；签发新 access token 不自动撤销同会话尚未到期的 access token，以支持多个标签页。
浏览器同页刷新使用 single-flight；同源多标签页使用 Web Locks 串行刷新，BroadcastChannel 传播登出和身份变更。Web Locks 不可用时停止自动恢复与刷新，要求显式重新登录；BroadcastChannel只传播退出/身份变更，不承担凭据或leader轮换。刷新请求不得由通用重试中间件盲目重发；响应丢失且轮换状态无法确认时允许重新登录，不降低重放检测标准。
access token 对应 sessionId，每次请求从主库校验 token 到期、session 撤销、用户禁用、密码版本、租户状态和租户到期。登出事务撤销会话并清除 cookie；客户端不能只删除本地 token 就报告“服务器登出成功”。网络失败时清理本地敏感状态，同时提示服务端撤销未确认；用户可重试或在会话管理中撤销。Vben 示例中的登出吞错逻辑要调整。
密码修改、密码重置、用户禁用撤销该用户全部会话；角色和套餐修改递增租户 authz_version，后续请求重新计算权限。业务数据库不可用时受保护请求拒绝服务；Redis 缓存故障不得放行，登录限流不可用则返回 503。
# 4. RBAC 与套餐能力
权限计算：有效权限 = 启用用户的启用角色权限并集 ∩ 租户有效权限集合 ∩ 启用权限目录。租户有效权限集合在套餐开通能力内，按 inherit（继承全部可用权限）或 custom（显式选择允许权限码）计算。平台可独立配置每个租户的权限，租户管理员再分配到角色；不能通过角色授权突破该上限。API 逐一声明权限码，例如 system:user:read、system:user:create；未知权限码默认拒绝。
菜单目录及权限目录由平台维护，租户角色只能引用已发布且已开通的目录项。菜单决定导航，按钮权限码决定页面操作；真正的数据访问仍由 Go 检查。路由存在或按钮可见不代表 API 有权限，隐藏菜单也不应被误当成撤销 API 权限。
R1 普通用户不能管理授权；只有受保护的 tenant_admin 可维护角色与用户角色关系。tenant_admin 的权限由启用目录、套餐能力和每租户权限上限共同计算，不能通过角色编辑器添加平台权限，也不能删除或编辑其保留角色。至少保留一个启用的 tenant_admin，移除或禁用最后一位管理员需事务加锁校验。
M2 admin 授权只读取 system_user_roles 的有效关系，旧 users.role_code 不再作为授权回退。普通用户新增不携带角色，初始必须改密；只有独立 bootstrap 才会在同一事务内初始化保留角色并关联租户管理员。
平台运营权限也按角色明确分配，首期通过 bootstrap 初始化受保护 platform_admin。平台角色管理页面可在 R2 扩展，R1 不开放运营用户自行提权。
# 5. 数据范围
R1 支持 ALL、DEPT、SELF。2026-10-23 M5 首个增量加入 DEPT_AND_CHILDREN 和 CUSTOM_DEPTS，用户及审计模块的 API、角色页面已接入；其他资源仍需显式适配其归属字段。子树按当前有效树快照计算；自选仅含显式节点，不隐含本人或下级。操作与失败边界见 数据权限，当前验证进度见 M5 实施记录。
同一资源权限下，按角色分别求“该角色授予的权限 + 该角色的数据范围”，再并集。不能把角色 A 的用户读取权限套用到角色 B 的全部数据范围，否则会组合提权。并集为空时无权，ALL 覆盖其他范围，但始终受 tenant_id 限制。
M2 已实现的用户模块中，SELF 表示当前用户；未来业务模块需显式声明 owner_user_id。DEPT 依据请求时有效部门归属，不含下级，无部门时为空。每个资源在实现时显式声明数据归属字段；菜单等租户内配置资源不套用业务 owner 过滤，而采用专门的管理权限。
数据范围作用于分页、详情、修改、删除、导出、批量操作和统计，不只作用于列表。创建时校验 owner/dept 是否在可分配范围，更新时禁止把记录转移到范围外。无法访问的资源返回 404，减少 ID 探测；无操作权限返回 403。
用户个人资料走单独的 self-service DTO，只允许昵称、头像等字段，不接受角色、部门、状态、密码散列等敏感字段。账号管理 DTO 与个人资料 DTO 分开。
# 6. 隔离落实
- Actor 从有效会话生成，携带 actorKind、userId、tenantId、sessionId，业务服务不从 body/header 随意重建 Actor。
- 对租户资源的 repository 方法强制接收 TenantScope；缺失、零值或平台主体不能退化为全表查询。
- SQL 读写同时约束 tenant_id 与资源 ID；原生 SQL、关联、预加载、批量授权和 count 查询同样处理。
- 关联表保留 tenant_id，并通过复合外键和唯一索引限制跨租户关联；每个引用的 user/role/dept 均校验归属。
- 缓存 key 包含环境、租户、资源和版本；对象存储 key 包含租户命名空间，授权下载先查元数据归属。
- 后台任务保存受信的 tenantId，恢复执行上下文后校验租户状态，不能凭任务参数开启免隔离模式。
- 全局表只有显式列举的平台账号、租户、套餐、菜单/权限目录等；不能依赖“无 tenant_id 自动忽略”规则。
GORM Scope 仅是复用过滤条件的实现工具，不是全局安全保证。官方 Scope 文档 (opens new window)
# 7. 租户生命周期
创建 PENDING → 初始化成功 ACTIVE → 到期 EXPIRED / 人工停用 SUSPENDED
初始化失败仍是 PENDING，可幂等重试；不得返回可登录的半成品租户。
先创建 PENDING 租户记录；初始化将初始管理员、保留角色、套餐关联、状态变为 ACTIVE 与审计在同一个本地数据库事务内完成。失败回滚为 PENDING；重复初始化 ACTIVE 租户返回原结果而不重建账号。初始密码由显式初始化输入或短期激活流程设置，首次登录强制改密；不发送明文密码邮件。M3 还提供平台受保护的显式初始化表单/API，生产通过 HTTPS 与统一 JWE 内容加密通道提交；开发明文仅用于显式 loopback profile。口令不进入 URL、日志、审计、响应或持久化存储。离线初始化仍通过受控终端/运维 Secret 传递，不把密码放在命令行历史中。
停用和到期阻止登录、刷新及新业务请求。恢复需平台操作并审计；历史被撤销会话不自动复活。套餐降级立即收窄能力及每租户权限选择的有效交集，已有数据保留，超额配额阻止新增，不自动删除业务数据。配额检查和新增在同一事务锁定租户行，避免并发超额。M3 使用已索引的未删除账号 count 作为权威用量，不维护双写计数器；停用账号及初始管理员计入，软删除释放。
M3 的内部状态沿用 pending/enabled/disabled，对外 expired 为读取时计算态。tenants.session_version 在启停或到期时间实际改变时推进，auth_sessions.tenant_session_version 固定签发时的值；每次认证与敏感管理写入均比较，停用恢复或到期续期不能复活旧会话。套餐与自定义权限变更只收窄权限并推进 authz_version，不要求重置账号。初始化以持久化 initialized_at 判定幂等，已初始化后即使停用/到期也不能借重试覆盖凭证。实现与证据见 M3 实施记录。
# 8. 必须验证的案例
| 场景 | 期望 |
|---|---|
| A token 查询/修改 B 的用户 ID | 404，无跨租户数据和副作用 |
| A 用户关联 B 的部门或角色 | 拒绝，数据库约束也不允许 |
| 修改 tenant-id 或 visit-tenant-id | 不切换身份；提供不支持的切换头时明确拒绝 |
| 无权限直接请求隐藏按钮 API | 403 |
| 角色 A 有 SELF 读取、角色 B 只有 ALL 编辑 | 读取仍只有 SELF，不能混合出 ALL 读取 |
| 用户禁用、改密、登出后继续使用 token | 401，新的请求不被授权 |
| 租户停用/到期或套餐能力撤销 | 新请求拒绝对应访问 |
| 跨标签页并发刷新 | 协调后不误触重放；旧 refresh 重放会撤销会话 |
| 复制平台 token 调租户 API | 401/403，不绕过租户隔离 |
| 两个并发请求删除最后管理员 | 至少保留一名启用管理员 |
| 初始账号登录或刷新返回必须改密 | 直接进入固定改密页，不请求 me/codes/menus；受限 token 不能调用业务 API |
| 改密页重载、改密成功或受限会话到期 | 分别恢复改密页、撤销会话并回登录页、要求重新登录 |
| HTTP 开发与 HTTPS cookie profile | 浏览器可保存/刷新/清除各自 cookie；生产未 HTTPS 时启动 WARN，按 Origin 选用 __Secure- 或 dev_ 刷新 Cookie |
以上作为 R1 集成与 E2E 验收要求。M1 已执行的身份、会话、基础授权与双库测试见 实施记录；用户已于 2026-10-23 确认 M1 人工验收，原 HTTPS 浏览器门槛已结项。M2 用户、多角色、最后管理员保护和按权限绑定的数据范围已通过双库自动验证及部分页面核对，详见 M2 实施记录；租户安全策略、解锁与口令有效期也已接入，审计/登录日志查询及独立权限已经接入；普通用户 SELF/DEPT/ALL 的用户与日志页面已在两库核对，用户于 2026-10-23 独立确认“M2人工验收成功”，原页面人工项据此结项，M2 已完成。
# 9. 多用户类型和多终端
目标身份模型由 realm、subjectType、subjectId、tenantId（平台可空）、clientId、sessionId 构成，避免只使用一个 userId。2026-10-26已落地schema v20的realm/client注册表、平台配置API/页面、现有平台/租户会话的audience/subject_type/subject_id/client_version绑定、同client会话上限与本人全端撤销；v21已追加独立会员口令认证、管理与本人注销，详见会员手册；v22已追加独立服务凭据与scope，v23–v26已追加批准回跳、提供方/绑定、明确来源会话、RP/backchannel退出和认证模式；Vben入口及真实双应用SSO/统一退出已验证。操作见 身份客户端与设备会话。realm 默认 platform、admin、member；服务身份独立为 service，不继承自然人的部门或角色。
| 用户类型 | 账号来源与权限 | 交付阶段 |
|---|---|---|
| 平台运营 | platform_users + 平台 RBAC | R1 |
| 租户后台用户 | users + 租户 RBAC/数据范围 | R1 |
| 会员/终端用户 | v21独立member_users/session/token与本人API，不能调用管理端 | 口令/绑定OIDC认证及本人注销已实现；会员商业业务另行扩展 |
| 服务账号 | v22独立service_accounts/credentials/tokens，受控JSON/JWE凭据交换与发布scope | 已实现，不继承自然人权限，不是通用OAuth2授权服务器 |
client registry 定义 clientId、audience、允许 grant、终端类型、会话上限和有效期；提供方记录及部署信任档案共同限定callback、post-logout和SPA return URL，不能由登录请求传入。当前注册表接受web、native、desktop、api四种终端类型；小程序渠道的专用凭据适配仍属后续接入，不冒充已认证支持。实际 App/小程序 UI 不属于 Vben 页面交付，R2 通过测试客户端完成认证协议验收。
终端策略支持同终端单会话/多会话、全端登出/指定设备撤销、按 client 的 token 时长、设备信息展示。deviceId 是风险提示和会话定位信息，不作为可信认证因素；强制单会话在数据库事务内锁定用户和 client 后执行，不能只靠缓存计数。
Web 使用本文 cookie + 内存 access；原生客户端使用系统浏览器授权码 + PKCE；产品化原生端若跨进程保存刷新凭据须使用系统安全存储。当前R2有限验收客户端仅保留进程内存，不提供长期缓存，也不复用浏览器cookie。小程序渠道凭据由独立适配器服务端验证，不把开放平台返回的用户标识直接当本系统授权。
# 10. SSO 架构
采用 OIDC Authorization Code + PKCE，对接成熟身份提供方；优先对接企业现有 IdP；需要自带 IdP 时评估 Go 服务候选（如 ZITADEL）或独立 Go 身份组件，默认不部署 Keycloak/JVM。Go 作为 relying party/BFF 验证登录结果并签发本系统的受限会话，不在此项目自写完整 OAuth/OIDC 授权服务器。多个业务应用注册到同一个 IdP，复用 IdP 登录会话，实现 SSO；本系统登录 cookie 不直接跨域共享。
支持两种部署：接入企业 IdP，或随平台部署统一 IdP 给多个应用使用。租户可配置独立 issuer/client，配置由平台审核，issuer/redirect/JWKS 来源只接受受控地址，防止任意 URL 访问。默认禁用按相同邮箱自动合并账号，绑定键为 issuer + sub + realm + tenantId。
SSO 登录：POST /api/{realm}/v1/auth/sso/start 校验可信 Origin 并创建一次性 state、nonce、PKCE verifier → 重定向授权页 → GET /oidc/{realm}/{tenantId}/{providerCode}/callback 消费 state 并在服务端交换 code → 校验 issuer、签名/允许算法、aud、必要时 azp、nonce、有效期 → 映射有效用户与租户 → 创建应用会话 → 设置刷新 cookie → 跳转固定白名单 SPA 地址。
回调是授权协议专用 GET 入口，不套用密码登录的 JSON/专用头要求；使用短期、一次性、HttpOnly、Secure、SameSite=Lax 的 state 关联 cookie，以支持跨站顶层回跳。业务 refresh cookie 仍按 Strict 策略。access/refresh token 不出现在 URL 或浏览器日志。
SSO 不绕过本系统的租户、账号状态、套餐和权限检查。IdP 登录成功但没有已绑定本地账号时拒绝或走审核邀请流程；账号首次绑定不能仅按前端给出的 tenantId 决定。SSO 用户禁用本地密码入口的策略由账号类型决定，不能让弱密码旁路 SSO。
区分本地登出和统一登出：本地登出只撤销应用会话；统一登出调用 IdP 的 RP-initiated logout，并在提供方支持时通过 back-channel logout 消息撤销按 issuer + sid/sub 关联的本地会话。具体 IdP 必须通过端到端登出测试；不声称第三方不支持时仍能立即登出所有应用。
验收：两个测试应用的 SSO、跨 realm token 拒绝、Web/原生 PKCE、多终端并发/踢出、过期与撤销、错误 state/nonce/issuer、回调重放、账号解绑、IdP 故障和本地停用。OIDC 协议参考 规范 (opens new window)，原生应用参考 RFC 8252 (opens new window)。
# 11. Redis 权限缓存（规划备查）
当前实现每次由主库裁决权限，没有启用下述权限结果缓存；Redis只承担已发布的限流、请求去重等职责。以下保留为后续性能方案，不能当作生产能力：
按 env:realm:tenantId:subjectId:authzVersion:packageVersion 缓存有效权限、菜单和数据范围计算结果；TTL 只限制残留时间，不能代替版本校验。访问主库读取当前会话/用户/租户/授权版本，版本匹配后复用 Redis 结果，减少复杂 JOIN 和树计算。
角色分配、部门归属、菜单/权限目录启停、每租户权限自定义、套餐能力变更在业务事务中更新受影响租户的 authz_version。平台权限 R1 直接从权威目录计算，后续缓存需引入独立 platformPolicyVersion，不借用某个 tenantId。变更后发送失效事件用于预热/删除；即使事件延迟，版本校验仍拒绝旧结果。
菜单和权限码的前端缓存同样绑定版本，不能从持久化旧状态恢复权限。Redis 故障回源主库计算并受限流保护；主库故障时拒绝授权。此设计优先保证提交后的新请求立即按新权限处理，后续只有在明确接受撤销延迟窗口时才评估缓存权威版本。
Go 身份提供方候选仍需验证部署和许可、数据存储及退出登录能力，不能仅因有 Go SDK 就判定服务端无 Java。平台自研服务与默认部署不引入 JVM；企业已存在的外部身份服务按协议接入，不把其内部实现纳入本项目代码。若选用独立 IdP，其存储要求作为独立基础设施记录，不冒充七种业务库均可直接承载该产品。
# OIDC 管理接入（v23）
提供方与外部绑定现由独立SSORegistry显式注入，部署信任档案限定网络与文件能力，平台控制来源配置，当前租户管理员维护本租户admin/member绑定。精确issuer/sub绑定到现有明确类型主体，不按邮件推断身份，不提供自动注册。解绑保留外部键，墓碑账号不可恢复绑定。配置启停不等于已签发SSO会话；v24已追加一次性状态、独立回调、明确来源的本地会话及当前撤销守卫，Web/原生HTTP与签名backchannel已通过本地双库专项；v25继续追加先本地撤销的RP主动退出、固定Web退出关联及有界材料到期清理；原生系统浏览器有限客户端已在macOS与同一个真实IdP应用三协议验证；v26已追加认证模式、当前来源守卫、最后方式与口令恢复管理员保护；Vben实际入口和两个独立Web应用的真实IdP SSO、故障补偿、RP返回及签名撤销已通过本地验收。操作和限制见OIDC提供方与外部绑定。
HTTPS下的新SSO关联/刷新Cookie采用__Host前缀、Secure、根路径且不设置Domain，HttpOnly阻止脚本读取；关联用Lax，刷新仍为Strict。Cookie名称分离realm/client/精确Origin，state同时约束实际回调路径及Cookie传输标记，不允许开发Cookie替代HTTPS证明。Cookie主机不以端口隔离，部署时同一Cookie主机内的服务须属于同一信任边界。浏览器属性约束见Set-Cookie规则 (opens new window)。
RP主动退出区分local_only、unavailable、redirect_ready与returned；后三者均不能单独证明所有应用已退出。Web退出回跳精确登记并使用独立state/Cookie；公共原生不附加动态退出回跳，只交付携带已验证hint的上游URL。到期材料由worker清空，真实会话绝对期限缩短时维护期限同事务收紧，签名backchannel也清除已由RP本地撤销的重试材料。标准依据RP-Initiated Logout 1.0 (opens new window)，真实IdP端到端验收仍须继续。