三层规则模型
Sudomimus 上的每一个应用都由三层相互独立的规则把关。每一层回答一个不同的问题、由各自独立的配置驱动，并在认证流程中的不同位置被检查。三层都没有隐式默认值：一层里没有规则，就意味着这一层什么都不放行。
在 Sudomimus Theater 中演练应用规则| 层 | 名称 | 回答的问题 | 检查时机 |
|---|---|---|---|
| Layer 1 | 认证规则 | 允许使用哪些认证方式？ | 向用户展示可选方式时，以及每一次实际的认证尝试。 |
| Layer 2 | 身份准入规则 | 允许哪些身份完成登录？ | 认证成功之后、把认证请求标记为 realized 之前。 |
| Layer 3 | 返回规则 | 如何把认证结果交给应用？ | /establish 时（针对声明的返回方式），以及运行时（如 /status-poll、设备码兑换或 OIDC /token）。 |
flowchart TD
Start["认证尝试"] --> Layer1{"Layer 1 —— 认证<br/>是否有允许的方式匹配？<br/>（层内 OR）"}
Constraints["可选的单次 Inquiry 收紧条件<br/>与应用规则层按 AND 组合"]
Constraints -. 字段存在时 .-> Layer1
Constraints -. 字段存在时 .-> Layer2
Constraints -. 字段存在时 .-> Layer3
Layer1 -->|通过 —— 与下一层 AND| Layer2{"Layer 2 —— 身份准入<br/>是否有允许的身份匹配？<br/>（层内 OR）"}
Layer2 -->|通过 —— 与下一层 AND| Layer3{"Layer 3 —— 返回<br/>是否有允许的交付路径匹配？<br/>（层内 OR）"}
Layer1 -->|不通过| Reject["拒绝<br/>允许列表默认拒绝"]
Layer2 -->|不通过| Reject
Layer3 -->|不通过| Reject
Layer3 -->|通过 —— 三层全部通过| TTL["TtlFold<br/>在所有匹配规则和限制中取最小值"]
TTL --> Allow["允许 realize 和初始签发"]
这样拆开后，三个维度可以分开配置。新开启一种认证方式，不会顺带放宽可登录身份的范围；收紧允许的回调域，也不需要动认证配置。
允许列表 + 默认拒绝
Section titled “允许列表 + 默认拒绝”每一层都是纯允许列表。新应用的三层均为空，必须显式添加规则后才能使用。系统不存在“全部放行”的隐式模式；删除任一层的最后一条规则，就会让应用停止接受登录，而不会回退到其他默认值。
这让配置错误更容易被发现：少配规则时登录会失败，而不是悄悄放行不该进入的人。
按 Inquiry 收紧
Section titled “按 Inquiry 收紧”应用级规则定义应用整体上允许的范围，单次登录通常可以更严格。例如，管理员入口可能只允许通行密钥，某个租户的入口则可能只允许特定邮箱列表。因此，/establish 请求接受三个可选的限制字段：
/establish 上的字段 |
收紧的层 |
|---|---|
authenticationConstraints |
认证规则（Layer 1） |
realizeConstraints |
身份准入规则（Layer 2） |
returnMethods |
返回规则（Layer 3） |
每个字段的形状与对应的规则形状对齐，所以两边用的是同一套词汇。
- 字段缺失 —— 这一层不做额外收紧；只看应用规则。
- 字段存在但是空数组 —— 直接拒绝。空收紧表达的是“什么都不放行”，而把应用里的规则删空已经能表达同样的语义。
- 字段存在且非空 —— 每一项都必须通过结构校验。在本次认证请求中，限制列表与应用规则按 AND 组合。
同层 OR、跨层 AND
Section titled “同层 OR、跨层 AND”当同一个评估点上有多条记录可能匹配时，组合方式如下：
- 同一层、同一来源的多条记录 = OR —— 例如，应用的多条认证规则只需任意一条匹配。
- 跨层 = AND；同层跨来源也 = AND —— 认证规则、身份准入规则和返回规则必须全部通过。每一层内，应用规则与可选的单次请求限制也必须同时放行。
因此，认证请求上的限制只能缩小允许范围，不能放宽应用规则原本禁止的内容。
Token TTL
Section titled “Token TTL”本节是规则层与单次认证请求约束之间 TTL 折叠语义的唯一文字参考。令牌与验证负责数值区间与令牌字段。
每条规则和每项认证请求限制都可以提供 accessTokenTtlSeconds 与 refreshTokenTtlSeconds。初始签发流程会收集所有匹配值，并在所有层和来源之间取最小值，让最严格的设置生效。Session API refresh 会保留初始签发点解析出的 TTL。
默认 access token 3 小时、refresh token 30 天。如果访问令牌 TTL 大于刷新令牌 TTL，则缩短访问令牌 TTL，使其等于刷新令牌 TTL。例如，访问令牌为 7 天、刷新令牌为 1 天时，最终两者均为 1 天。完整区间（access 60 秒 – 7 天；refresh 1 天 – 365 天）见 令牌与验证。
接下来读哪里
Section titled “接下来读哪里”每一层都有专门的页面，给出 schema、通配/匹配语义，以及一个实际示例：