配置模板

三层规则很灵活，但大多数应用都从少数几种形态起步。从下面挑一个最接近的模板，在 With 门户 里把规则填进你的应用，再做调整。

每一层都至少要有一条规则

本模型采用允许列表 + 默认拒绝：任一层为空时，应用都会拒绝所有人。要让应用正常工作，认证、身份准入和返回三层都必须至少有一条规则。如果登录在完成配置后仍被拒绝，请先确认三层均不为空。组合规则见概述。

下表中形如 *.example.com 的值是占位符——请替换成你自己的。每一层可以放多条规则；层内多条之间是 OR。

标准 Web 应用（无密码）

通行密钥加邮箱一次性验证码、开放注册、登录后重定向回你的站点。最常见的起点。

层	规则
1 — 鉴权	PASSKEY_USERNAMELESS、PASSKEY_REASONED、EMAIL_VERIFICATION
2 — 通行	EMAIL → { "allowedEmails": ["*"] }
3 — 返回	CALLBACK → { "allowedCallbackDomains": ["app.example.com"] }

带社交登录的 Web 应用

在无密码模板基础上加「使用 …… 登录」按钮。只加你想要的提供方；每个是一条 Layer 1 规则。

层	规则
1 — 鉴权	PASSKEY_USERNAMELESS、PASSKEY_REASONED、EMAIL_VERIFICATION、GOOGLE_OAUTH、GITHUB_OAUTH、DISCORD_OAUTH
2 — 通行	EMAIL → { "allowedEmails": ["*"] }
3 — 返回	CALLBACK → { "allowedCallbackDomains": ["app.example.com"] }

注意：仅用 Steam、Battle.net、X 登录的账户没有已验证邮箱，因此只有 EMAIL 规则的 Layer 2 会拒绝它们。如果你提供这些提供方，请按需把 EMAIL 规则与 STEAM_ID / EVERYONE 搭配使用（见下方公开应用模板）。

内部 / 团队工具（限定域名）

只有邮箱在你公司域名下的人才能登录。

层	规则
1 — 鉴权	PASSKEY_USERNAMELESS、PASSKEY_REASONED、EMAIL_VERIFICATION
2 — 通行	EMAIL → { "allowedEmails": ["*@yourcompany.com"] }
3 — 返回	CALLBACK → { "allowedCallbackDomains": ["tool.yourcompany.com"] }

若想（额外或改为）强制这些用户走你自己的身份提供方，见使用你的 IdP 登录与域名登录策略。

Steam 游戏（静默、游戏内登录）

通过 Steam 发行、无需浏览器就把玩家登录进来的游戏。

层	规则
1 — 鉴权	STEAM_TICKET → { "allowedSteamAppIds": [480] }
2 — 通行	STEAM_ID → { "allowedSteamIds": ["*"] }
3 — 返回	DIRECT_ISSUE

把 480 换成你真实的 Steam App ID。若想让同一批玩家也能通过浏览器的「使用 Steam 登录」按钮登录，再加一条 STEAM_OPENID Layer 1 规则——它解析到同一份 Steam 身份。端到端流程见原生客户端。

CLI / 无头服务（AccessKey）

以一个已知的、已存在的账户身份、用预先签发的凭据进行认证的命令行工具或服务。

层	规则
1 — 鉴权	ACCESS_KEY_DIRECT
2 — 通行	SECTOR_SUBJECT → { "allowedSectorSubjects": ["sub_..."] }（或一条能匹配该绑定账户的 EMAIL 规则）
3 — 返回	DIRECT_ISSUE

AccessKey 不能创建新账户——它始终以某个具体的已存在账户身份行事，所以 Layer 2 用来锁定那个账户。见原生客户端。

OIDC 接入方（relying party）

把应用暴露给标准的 OpenID Connect 客户端（authorization_code + PKCE）。

层	规则
1 — 鉴权	PASSKEY_USERNAMELESS、PASSKEY_REASONED、EMAIL_VERIFICATION（以及任意社交提供方）
2 — 通行	EMAIL → { "allowedEmails": ["*"] }
3 — 返回	OIDC → { "redirectUris": ["https://app.example.com/oidc/callback"], "allowedScopes": ["openid", "email", "profile", "offline_access"], "tokenEndpointAuthMethod": "private_key_jwt" }

公开客户端用 "tokenEndpointAuthMethod": "none"（无论哪种都必须用 PKCE）。端到端配置见 OIDC 接入方。

桌面应用（浏览器轮询）

拉起系统浏览器登录、随后轮询结果的桌面或 Electron 应用。

层	规则
1 — 鉴权	PASSKEY_USERNAMELESS、PASSKEY_REASONED、EMAIL_VERIFICATION
2 — 通行	EMAIL → { "allowedEmails": ["*"] }
3 — 返回	STATUS_POLL

/establish → /status-poll → /redeem 的浏览器轮询流程见原生客户端。

真正面向公众的应用（不设身份门槛）

任何能通过 Layer 1 的人都放行——包括没有已验证邮箱的账户（仅 Steam、仅 Battle.net）。当你完全不想限制谁能登录时用它。

层	规则
1 — 鉴权	你提供的任意方式（例如 PASSKEY_USERNAMELESS、EMAIL_VERIFICATION、STEAM_TICKET……）
2 — 通行	EVERYONE
3 — 返回	CALLBACK / STATUS_POLL / DIRECT_ISSUE / OIDC —— 看你的客户端用哪种

EVERYONE 会无条件匹配，因此在 OR 语义下会覆盖其他所有 Layer 2 规则。请谨慎使用，详见身份准入规则。

挑好模板之后

• 限制单次请求。 /establish 可以通过 authenticationConstraints、realizeConstraints 和 returnMethods 缩小任意一层的允许范围，例如创建仅供管理员使用的登录链接。详见概述。
• 决定请求哪些资料。 应用是否拿到用户的邮箱或姓名是另一个独立设置——见身份声明与共享。
• 设置令牌时长。 每条规则都能覆盖 access / refresh token 的 TTL；留 null 则继承平台默认值。