身份访问证据模型与工具选型：从主体到撤销的完整链路
凌晨的变更审计显示，一名已经离职三天的工程师仍然调用了生产发布接口。身份平台里用户已被停用，应用日志却只留下一个邮箱地址和 200；网关没有记录令牌发行者，资源服务没有记录策略版本，团队也无法判断请求来自旧浏览器会话、个人访问令牌，还是某个仍以该员工名义运行的自动化任务。停用动作确实发生过，但从身份源到资源端的撤销链没有任何一段能够证明自己生效。
另一支团队遇到相反的问题：登录页、MFA 和网关都工作正常，财务应用仍把普通员工识别为管理员。根因不是认证失效，而是应用把 groups 声明直接映射为本地角色，旧组名迁移后发生碰撞。身份事故很少只属于“登录模块”；它往往是主体、凭证、令牌、会话、策略、资源与审计证据在某个边界发生了错位。
先回答资源端究竟相信了谁
身份系统的起点不是用户名，而是 principal，也就是一次决策中可被唯一指认的主体。它可能是员工、承包商、客户、服务账号、工作负载、设备或进程。邮箱、显示名和部门都可能变化，也可能重复；可用于关联的主体标识应至少绑定发行者、租户或信任域，例如 (issuer, subject)、云账号内的 role session principal，或 SPIFFE ID。只保存一个 userId，无法证明它来自哪个权威身份源。
主体随后使用 credential 证明自己有资格参与认证。密码、通行密钥、客户端私钥、X.509 证书、云实例证明和外部 OIDC assertion 都属于凭证或凭证材料。认证成功后，系统可能签发 token 或创建 session；它们是受限、可过期的后续访问能力，不应被当成永久身份档案。policy 根据主体属性、上下文、动作和资源作出决定，resource 负责执行决定，audit 记录发生了什么，revocation 则让旧能力在主体离职、设备丢失、密钥泄露或策略改变后停止生效。
可以用一条最小访问记录表达这七段关系：
{
"principal": {"issuer": "https://id.example.test", "subject_hash": "sha256:...", "type": "workforce"},
"credential": {"method": "webauthn", "assurance": "phishing-resistant"},
"token_session": {"kind": "access_token", "audience": "release-api", "session_ref": "s_7f..."},
"policy": {"id": "release-approval", "version": "2026-07-17.3", "decision": "allow"},
"resource": {"id": "prod/checkout", "action": "deploy"},
"audit": {"correlation_id": "req_91...", "occurred_at": "<RFC3339>"},
"revocation": {"grant_ref": "g_2a...", "status": "active"}
}这里的摘要和引用值用于关联，不应把完整 token、cookie、断言、授权码、密码或私钥写进日志。资源服务至少要知道自己接受哪个 issuer、哪个 audience、哪种主体以及哪版策略；否则“验签成功”只能证明某把密钥签过一段数据，不能证明当前请求应被允许。
凭证、令牌与会话不能互相顶替
凭证通常用于获得另一个更短期的能力。用户用通行密钥完成认证，客户端经授权码流程得到 token，应用再用受保护 cookie 指向服务端 session。三者生命周期、泄露后果与撤销入口不同：改密码不一定终止已有会话；删除浏览器 cookie 不一定撤销 refresh token；撤销 OAuth grant 也不一定清理应用自己的 session。把它们统称为“登录态”，排障时就会误删一层、遗漏另外两层。
NIST SP 800-63B 将认证会话与认证器分开讨论，强调会话秘密的安全传输、生命周期、重新认证和终止。RFC 9700 则给出 OAuth 部署的安全基线，包括授权码与 PKCE、精确 redirect URI、refresh token 重放防护和受众限制。它们共同指向一个工程结论：长期身份证明、短期访问能力和应用交互状态必须分别建模、分别存储、分别撤销。
项目配置可把这些边界显式化：
identity:
issuer: ${IDENTITY_ISSUER}
principalKey: [issuer, subject]
acceptedCredentialMethods: ${ACCEPTED_AUTH_METHODS}
tokenValidation:
audience: release-api
allowedAlgorithms: ${TOKEN_ALG_ALLOWLIST}
clockSkew: ${TOKEN_CLOCK_SKEW}
session:
store: redis
cookieName: __Host-release_session
idleTimeout: ${SESSION_IDLE_TIMEOUT}
absoluteTimeout: ${SESSION_ABSOLUTE_TIMEOUT}
authorization:
policyBundle: ${POLICY_BUNDLE_DIGEST}
defaultDecision: denyprincipalKey 防止跨 issuer 主体碰撞；audience 防止为其他 API 签发的 token 被复用；算法允许列表避免客户端按输入自行降级；会话空闲和绝对时限限制失陷窗口；策略摘要让一次允许决定能够回放。数值应由业务风险、交互体验与恢复能力决定，而不是照抄示例。
策略决定必须和资源执行闭环
认证回答“这个主体如何被确认”，授权回答“它能否对这个资源执行这个动作”。RBAC 适合稳定角色，ABAC 可结合部门、设备、时间和资源标签，关系授权适合表达所有者、成员与层级关系。工具可以是应用内策略、网关插件、云 IAM、OPA 类策略引擎或身份平台的授权服务；真正的选型信号不是功能数量，而是决策点在哪里、资源模型是否匹配、策略能否版本化以及拒绝是否有证据。
资源端不能只接收上游传来的 X-User 或 X-Groups 就认为授权完成。若由可信代理注入身份头，必须清除外部同名头、限制到受信网络路径、认证代理自身并固定头部合同；资源服务仍要把动作与资源交给明确策略。对资金、发布、密钥等高风险动作，还应把环境、审批、认证强度和最近重新认证时间纳入决策。
下面的 Rego 片段展示资源决策的最小输入。它不会因为主体“已登录”就放行，只有发行者、受众、动作、环境与审批同时匹配才允许：
package release.authz
default allow := false
allow if {
input.principal.issuer == "https://id.example.test"
input.token.audience == "release-api"
input.action == "deploy"
input.resource.environment == "production"
input.context.approval_count >= 2
input.context.auth_age_seconds <= input.policy.max_auth_age_seconds
}正向实验使用隔离主体、正确 issuer 和 audience、两个有效审批以及满足策略的认证时间，预期策略返回 allow=true，资源服务写入发布审计。反向实验分别替换错误 audience、减少审批数、把认证时间调到阈值之外，并让资源服务直接收到伪造身份头；每项都应在执行发布前返回拒绝。失败证据应包含策略 ID、版本、原因码和 correlation ID，不记录 token 原文。
用正反实验验证完整证据链
单次成功登录不足以证明系统正确。最小实验应先创建隔离主体和最低权限资源，完成认证、token 签发、会话建立与资源访问，再沿相同 correlation ID 找到身份平台、代理、策略点和资源端四处记录。成功结果不仅是 HTTP 200，还包括主体标识一致、audience 正确、策略版本可追踪、资源动作确实发生且审计不含秘密。
反向实验要主动破坏每个边界：用错误 issuer 的 token、正确签名但错误 audience 的 token、过期 token、已撤销 session、缺失审批的动作以及不存在的资源。预期结果是第一个负责该条件的组件拒绝请求，后续组件不再执行副作用。若所有错误最后都只表现为网关 401，说明证据分类仍不足；若资源已经写入后才出现拒绝日志，则执行与授权次序已经颠倒。
一个不依赖真实 token 的本地决策实验可以先验证输入合同：
set -eu
opa eval --fail-defined --format pretty \
--data policy.rego --input allow.json 'data.release.authz.allow'
if opa eval --fail-defined --format raw \
--data policy.rego --input wrong-audience.json 'data.release.authz.allow' \
| grep -qx true; then
echo 'ERROR: wrong audience was accepted' >&2
exit 1
fi
echo 'PASS: invalid audience did not produce allow=true'正例预期输出 true；反例不应得到 true。这只验证策略输入与决定，不能替代真实 OIDC 验签、代理头清理、资源副作用和撤销传播实验。上线门禁要把这些独立实验串起来，并明确哪一段由哪个团队维护。
撤销要以旧能力持续失败为准
RFC 7009 允许撤销端点对未知 token 返回成功，因此一次 HTTP 200 不能证明旧 token 已失效。撤销结果必须在资源端验证：先用测试 access token 访问最低权限资源成功，撤销 grant 或 refresh token，等待约定传播预算，再用旧 access token 访问并尝试刷新；两者都应失败，同时审计能关联撤销原因、主体、客户端和资源。
离职回收至少包含目录状态、组成员、身份平台会话、OAuth grant、应用 session、个人访问令牌、服务账号委派、设备注册和资源本地账号。SCIM active=false 可能只停用目录对象，不会自动终止离线会话；短期 JWT 在资源端离线验签时，也可能活到自身过期。架构必须明确“立即撤销”依靠在线 introspection、事件传播、denylist 还是短 TTL，并把传播上限写入 SLO。
回收实验应保存脱敏时间线，而不是截一张控制台页面：
T0 principal disabled at authoritative directory
T1 provisioning target marks account inactive
T2 identity provider rejects new authentication
T3 application session is terminated
T4 refresh attempt is rejected
T5 resource rejects old access capability
revocation_propagation = max(T1..T5) - T0任一时间点缺失都表示责任边界没有证据。对于无法即时撤销的离线 token，要缩短有效期、限制 audience 与权限，并在高风险动作前重新检查主体状态；不能用“最终会过期”代替离职核销。
观察性要定位第一处失效边界
身份日志既要可关联，又要克制。推荐记录 issuer、tenant/realm、client ID、匿名化 subject、credential method、authentication context、audience、scope 摘要、session/grant 引用、policy ID/version、resource/action、decision/reason code、key ID 与 correlation ID。禁止记录完整 assertion、token、cookie、authorization code、client secret、恢复码和不必要的个人属性。
排障时沿链条寻找第一个不成立的事实。发现文档或 metadata 失败，检查 issuer、DNS、TLS 与缓存；签名失败检查 kid、JWKS 轮换与算法；token 语义失败检查 audience、时间和 tenant；session 失败检查 cookie 属性、服务端存储和节点一致性；401 回到认证与 token，403 检查策略和资源映射；资源成功但审计缺失，则补偿性控制本身不可靠。
指标不应使用用户、token 或 session 作为高基数标签。按 issuer、client、结果、原因类别和区域聚合登录、换 token、刷新、拒绝、撤销和策略延迟；详细主体关联留在受控审计存储。告警要围绕基线偏离，例如未知 kid 激增、单 client 刷新失败、撤销传播超预算、策略默认拒绝率突变，而不是笼统监控“登录失败数”。
从证据缺口反推工具组合
没有一个 IAM 产品能够独自完成全部七段。企业目录或 workforce IdP 管理人员主体与认证；CIAM 平台处理客户身份；OIDC/SAML 代理建立联邦；SCIM 连接器传播账户生命周期；云 IAM 与策略引擎作出资源授权；应用 session 存储维持交互状态；SIEM 或日志平台保存跨边界审计。选择工具时，先标出当前哪段没有权威数据、哪段无法拒绝、哪段无法撤销，再评估产品能力。
概念验证应回答这些问题：主体唯一键能否跨租户稳定；凭证强度和认证上下文能否进入策略；token 的 issuer、audience、算法和 TTL 能否固定；会话能否按主体、设备或 grant 终止；策略是否版本化并默认拒绝；资源是否独立执行授权；审计能否跨组件关联；撤销是否在预算内到达资源端。只演示登录页和控制台用户列表，会把最昂贵的故障留到生产环境。
自建平台适合需要深度协议控制、数据驻留与可定制连接器的团队，但数据库、缓存、签名密钥、升级和 24 小时响应也由团队承担。托管平台降低基础设施运维，却引入租户配额、外部依赖、日志导出、数据边界和退出迁移约束。选择不应按“开源或 SaaS”二分，而应比较身份数据权威、协议适配、撤销时延、可观测性、容量、运营责任和退出成本。
容量与成本藏在刷新、同步和审计里
身份容量不等于登录 TPS。峰值还包括授权码交换、token 刷新、设备轮询、JWKS 与 metadata 刷新、session 读写、SCIM 批处理、策略查询、管理员 API、审计导出以及上游恢复后的重试积压。短 TTL 降低失陷窗口，却增加刷新、签名、数据库和网络开销；长 TTL 降低运行成本，却拉长撤销窗口。二者必须由风险和容量共同决定。
压力实验至少覆盖冷启动 metadata/JWKS、正常登录峰值、批量刷新、目录全量同步、签名密钥轮换、上游限流和缓存失效。记录 p95/p99 延迟、错误分类、数据库连接、缓存命中、签名吞吐、队列积压和撤销传播。对 SaaS 还要观察外部 API 限流和日志导出延迟；具体配额和计费能力应在采购与上线时查阅对应官方页面，不能固化为永久常量。
成本归属也要落实到 owner。平台团队负责可用性、信任与密钥；安全团队负责认证强度、策略基线和事件响应；应用团队负责本地 session、资源授权与数据最小化；HR 或目录团队负责人员状态权威；资源 owner 负责高风险动作。没有 owner 的 client、策略、服务账号和 SCIM 连接都应进入下线队列。
迁移和退出从双重证据开始
迁移身份平台时，先导出 client、issuer、redirect URI、scope、claim、组映射、会话、SCIM 连接、签名与加密密钥、资源信任和 owner 清单。新旧平台并行期间，资源端可以暂时接受两个明确 issuer，但主体映射、策略版本和审计必须区分来源，不能把两个租户的同名用户合并。先迁移低风险 client，验证新登录与旧能力拒绝，再逐步切换高风险资源。
回滚条件要在变更前确定：新 issuer 的错误率、撤销时延、SCIM 积压或资源拒绝超过阈值时，停止新授权并恢复旧入口；已经在新平台签发的会话和 token 仍需按策略处理，不能只切 DNS。密钥轮换要保留可控重叠窗口，使资源端同时认识新旧公钥，但签发端应只使用新私钥；窗口结束后确认旧 kid 不再出现。
安全退出的完成证据是旧 issuer 不再被任何 client 和资源信任，旧 session、grant、refresh token、SCIM token、client secret 与管理员账号均被撤销，代理路由、DNS、webhook 和日志导出被解除，用户数据、审计、备份和密钥副本按保留策略迁移或销毁。停止容器或取消订阅只结束了服务费用，没有结束信任关系。七段证据同时闭合，身份系统才真正从“能登录”提升为可治理的访问基础设施。