企业官网建设流程全解析

Authelia 的 OpenID Connect 1.0 技术细节剖析：Access Token、ID Token、Claim 稳定性与 Claims 获取机制

【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia

本文基于 Authelia 官方技术博客《Technical: OpenID Connect 1.0 Nuances》展开，深度讲解 OpenID Connect 1.0 规范中最容易被误解、也最容易在实现中踩坑的三个核心概念：Access Token 与 ID Token 的职责分野、sub/iss之外的 Claim 不具备身份绑定价值、以及 Claims 通过 Scope 与 Claims Parameter 获取的真实语义。读者读完本文后，将能够正确区分两类 Token 的受众与用途，理解为什么"用 email 或 username 绑定身份"是危险做法，并掌握 Authelia 作为 OpenID Connect 1.0 Provider 在 Claims 策略上的底层实现与配置方式。

一、为什么这篇技术文章值得读

Authelia 是一个面向 Web 应用的单点登录（SSO）与多因素认证（MFA）门户，其 OpenID Connect 1.0 Provider 实现已通过 OpenID 官方认证。本文面向三类读者：

• 对 Authelia 近期围绕 Claims 所做的设计决策感兴趣的人（如claims_policy、id_token_audience_mode等配置的动机）；
• 正在实现 OpenID Connect 1.0 规范（Provider 或 Relying Party）并希望少走弯路的人；
• 对规范本身感兴趣的普通技术爱好者。

作者在文中坦言，理解这套规范花费了数年时间，而阅读这篇文章大约只需要 20 分钟。文章所讨论的每个概念之间都高度关联，一旦理解了它们如何相互作用，就能感受到规范设计背后的"管弦乐"式整体构思。

相关阅读：本文的范畴属于 Authelia 技术类博客（Technical 分类），与仓库中的其他内容如 README.md、配置参考文档 互为补充。

二、Access Token 与 ID Token：两种完全不同的 Token

2.1 设计初衷：一个不透明，一个必须是 JWT

在 OpenID Connect 1.0 规范最初构思时，Access Token 并没有统一的格式，其格式完全由实现方决定。实际上，Access Token 对于使用它的那一方（如 Relying Party）而言是完全不透明、无意义的。这一点非常重要，它是理解 Access Token 设计意图的基石。

与之形成鲜明对比的是，ID Token 严格来说必须是一个 JSON Web Token（JWT）。ID Token 的格式与内容是严格定义的，其存在目的就是"唯一标识一个用户"。

多年以来，围绕这些 Token 的用途产生了一些混淆：

• Access Token 的语义只对Authorization Server（授权服务器）或深度集成的Resource Server（资源服务器）有意义；
• 无论 Access Token 是不透明形式还是 JWT 形式，都可以被Introspection（内省），但这通常是 Resource Server 的职责，而不是 Relying Party 的职责；
• 随着 [JSON Web Token Profile for OAuth 2.0 Access Tokens]（RFC 9068）被批准，越来越多的 Provider 开始用 JWT 作为 Access Token，人们也越来越倾向于用 Access Token 来判断用户身份——但这不是 Access Token 的设计意图，甚至是有害的。

OpenID Connect 1.0 正是为了解决 OAuth 2.0 的这一缺陷而诞生，其解决方案就是 ID Token：它专门用于承载能够唯一标识用户的信息。

2.2 通过aud一眼看出区别

从最终受众（audClaim）的角度看，ID Token 与 Access Token 的区别一目了然。根据 RFC 7519 第 4.1.3 节，aud（audience）标识 JWT 的目标接收方。

下面两个示例分别是Authorization Code Flow下有效内容的 ID Token 与 Access Token，参数如下：

1. Client ID：K2LQE4XRC54N7C2F5ZLF
2. Authorized Audience：https://auth.example.com/api/oidc/introspection
3. Scopes：openid profile email

{ "jti": "91de5882-ff69-46b6-b13b-165199f3191f", "iss": "https://auth.example.com", "sub": "d2fdc83d-d7ad-4ced-81d8-0bb87db4a127", "aud": "K2LQE4XRC54N7C2F5ZLF", "exp": 1745755215, "iat": 1745755000 }

{ "jti": "f30450c1-a60c-43ab-b855-e670f84ba45a", "iss": "https://auth.example.com", "sub": "d2fdc83d-d7ad-4ced-81d8-0bb87db4a127", "aud": "https://auth.example.com/api/oidc/introspection", "exp": 1745755215, "iat": 1745755000, "client_id": "K2LQE4XRC54N7C2F5ZLF", "scope": "openid profile email" }

对比这两个 Token，可以得出几个关键结论：

1. ID Token 的aud是 Client ID。规范要求它必须（可以附带额外值），这清楚地表明Client 才是 ID Token 的预期接收方。
2. Access Token 的aud不是 Client ID，而是内省端点等资源地址。因为 Client 不是 Access Token 的预期接收方，不应该用它来校验用户身份。
3. Access Token 有scopeClaim，而 ID Token 没有。这不是疏忽：ID Token 的意图非常明确——分享用户身份，因此无需 scope；而 Access Token 唯一的意图就写在它的名字里——用于"访问"（access）某些资源。这正是 Scope 与 Audience 概念存在的原因：与其让 Token 拥有"一刀切"的访问权，不如用它们将访问精确限制到特定端点与动作上。

2.3 一个特殊的例外：Client Credentials Flow

与 Authorization Code Flow 中sub通常是Resource Owner的 subject identifier 不同，Client Credentials Flow 会让 Access Token 的sub通常是Client ID。虽然技术上可以尝试借此校验"身份"，但这并非该 Access Token 格式的设计意图，规范中也没有任何常规条款保证这一点一定会如此。

2.4 谁该用哪个 Token：职责总结

• Access Token：供 Authorization Server 在User Information Endpoint、Introspection Endpoint、Revocation Endpoint及其实现的其他端点使用；或者供对 Token 校验方式有深入理解的 Resource Server 使用。
• ID Token：供Relying Party使用，作为"用户是唯一个体、或至少已授权访问其账户"的可验证凭证。

从 Authelia 的源码也可以印证这一分工。在 internal/oidc/const.go 中可以看到GrantTypeClientCredentials、GrantTypeAuthorizationCode等授权类型常量，以及ScopeOpenID、ScopeProfile、ScopeEmail、ScopePhone、ScopeAddress、ScopeGroups等 scope 常量；而 internal/oidc/claims.go 中的ClaimsStrategy接口分别定义了HydrateIDTokenClaims、HydrateAccessTokenClaims、HydrateUserInfoClaims、HydrateClientCredentialsUserInfoClaims四个独立的"注水"（hydrate）方法，说明三种 Token/端点使用不同的 Claim 填充逻辑，从实现层面落实了"各司其职"的规范语义。

三、Claim 稳定性与唯一性：身份绑定的根基

3.1 一个危险的行业趋势

大多数 OpenID Connect 1.0 Provider 实现都提供多种 Claim：email、username、可读姓名（name）等。但一个令人担忧的趋势是——无论是企业级还是开源项目，都喜欢随意挑选一个 Claim 来绑定身份，甚至很多人根本不做绑定，仅仅因为用户名或邮箱匹配就认定用户已登录。

这不是规范所指示的做法。OpenID Connect 1.0 明确规定：这些 Claim不得用于身份绑定。规范将我们的注意力引向一个事实——sub与iss是唯一能让 End-User 被清晰识别的Stable and Unique（稳定且唯一）Claim。

3.2 规范的原文

OpenID Connect 1.0 的 Claim Stability and Uniqueness 一节原文如下：

The sub (subject) and iss (issuer) Claims, used together, are the only Claims that an RP can rely upon as a stable identifier for the End-User, since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2. Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.

All other Claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users, and Issuers are permitted to apply local restrictions and policies. For instance, an Issuer MAY re-use an email Claim Value across different End-Users at different points in time, and the claimed email address for a given End-User MAY change over time. Therefore, other Claims such as email, phone_number, preferred_username, and name MUST NOT be used as unique identifiers for the End-User, whether obtained from the ID Token or the UserInfo Endpoint.

翻译过来即是：sub（subject）与iss（issuer）Claim 组合使用，是 RP 唯一可以信赖的 End-User 稳定标识符——sub在特定 Issuer 内对特定 End-User 必须本地唯一且永不重新分配；因此对给定 End-User 而言，唯一有保证的唯一标识符就是iss+sub的组合。而所有其他 Claim（如email、phone_number、preferred_username、name），无论是来自 ID Token 还是 UserInfo Endpoint，都不具备跨时间稳定、跨用户唯一的保证，Issuer 可以自由应用本地限制与策略（例如在不同时间将同一个 email 值复用于不同用户，或允许用户的 email 变更），因此不得用作 End-User 的唯一标识符。

3.3 为什么这会带来真实伤害

一旦意识到 Provider 允许用户修改 email 或 username，忽略这一点的严重后果就非常清楚了：

• email、username 是可变属性，不是标识符；
• iss与sub才是为用户设计的稳定标识，无论其他值如何变化都不应改变；
• 这不仅关乎安全，也关乎无缝的用户体验：仅仅因为用户改了邮箱就被拒绝登录某个应用——如果你没有使用正确的 Claim，这就会真实发生。

3.4 与 Access Token 概念的联动

这一点与第一部分的结论紧密相连：Access Token 可能以某种方式标识 End-User，但规范并不要求它这样做。事实上，Access Token 甚至可能不是 JWT——只要 Authorization Server 自己能理解它，格式完全由 Provider 决定。

3.5 那么这些可变 Claim 存在的意义是什么？

聪明的读者可能会问：既然不能用来绑定身份，这些 Claim 为什么还存在？它们主要有三个功能（并非穷举，但足以说明原则）：

1. 注册流程中的信息提示：在 Registration Flow，或某些 Identity Binding Flow（即把sub/iss绑定到已有身份）中，向尚未登录的 Relying Party 提供有用的信息或提示，例如预填表单。
2. 临时获取 Resource Owner 信息：为已经绑定身份的 Relying Party 提供其不愿自行存储的 Resource Owner 信息，例如在执行授权流后临时获取收货地址以完成一次购买。
3. 更新既有绑定身份的最新信息：让 Relying Party 能够获得已绑定身份的 Resource Owner 的最新详情，例如更新联系方式。

四、Claims 可用性：Scope 与 Claims Parameter

4.1 普遍的误解

规范提供了多种请求与授予 Claims 的方式，但很多人错误地认为：Claims 要么只在 ID Token 里、要么总是在 ID Token 里、甚至（如第一部分所述）在 Access Token 里。这种假设源于"某些 scope 授予 RP 访问某些 Claim 集合"的直观印象。但规范的真实意图是什么？

OpenID Foundation 的 "How OpenID Connect Works" 一文对此有权威表述：

An identity token represents the outcome of an authentication process. It contains at a bare minimum an identifier for the user (called the sub aka subject claim) and information about how and when the user authenticated. It can contain additional identity data.

即：身份令牌是认证过程的产物，至少包含用户标识符（sub，即 subject claim）以及用户"如何、何时"认证的信息，并且可以包含额外的身份数据。

细看 ID Token 的标准 Claim 集，可以发现 ID Token 默认的 Claim 集非常精简，而"如何请求额外 Claim、在哪些场景下必须包含额外 Claim"都有明确的规定。

4.2 Scope 参数：scope 不等于"把 Claim 塞进 ID Token"

"使用 Scope Values 请求 Claims"一节有一段关键论述：

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued.

即：当response_type会导致 Access Token 被签发时，profile、email、address、phone这些 scope 所请求的 Claims 是从 UserInfo Endpoint 返回的，而不是放进 ID Token。规范并不禁止 Provider 在 ID Token 中返回这些 Claim，但强烈建议不要默认这么做。

紧接着还有另一句关键论述：

However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.

这进一步固化了该观点：只有当不使用 Access Token 时（即response_type仅为id_token的 Implicit Flow 变体），Provider 才被明确要求将那些本应在 UserInfo Endpoint 可访问的 Claims 全部填充进 ID Token。Implicit Flow 是唯一可能不产生 Access Token 的流程，而id_token单一响应类型是唯一的一种变体。

4.3 这如何与第一部分呼应

• Access Token 的用途就是访问 Authorization Server 上的特定 API（如 UserInfo Endpoint）；
• ID Token 是 Resource Owner 唯一身份的静态快照；
• 而 UserInfo Endpoint 的请求能够获取关于用户最新的信息；
• 三者结合，整个设计逻辑就完全自洽了。

那么问题来了：如果一个 Relying Party 不打算用 Access Token 访问 UserInfo Endpoint，为什么不直接用带form_postResponse Mode 的 Implicit Flow？该流程专为识别用户而设计：不会签发 Access Token，只返回 ID Token；响应通过form_post执行；ID Token 被多重签名甚至加密。除了缺乏客户端认证之外，该流程的大多数问题都可通过"仅通过form_post返回 ID Token"来缓解。安全顾虑固然是合理的解释，但使用 UserInfo Endpoint 带来的隐私与安全收益太过强大，以至于"不正确地实现"难以被接受。

隐私与安全收益具体体现在：UserInfo Endpoint 要求提供当前有效的 Access Token才能获取 Claims。这意味着：

• ID Token 无需包含隐私敏感信息；
• Claims 只会释放给持有有效 Access Token 的一方。

4.4 顺带一提：Refresh Token 的防护实践

与 Claims 交付方式无关，Authorization Server 可以采取几种实践来限制被盗 Refresh Token 的利用价值：

• 旋转 Refresh Token：在 Refresh Token Flow 中签发新 Access Token 的同时签发新的 Refresh Token，并作废旧的。需要明确：这不能阻止被盗 Refresh Token 的第一次使用，但能在"已失效的 Refresh Token 被再次出示"时检测到盗窃行为。
• 签发 sender-constrained（发送者约束）Refresh Token：例如通过 mTLS 或 DPoP，将 Token 绑定到"被签发给的特定客户端实例所持有的密钥"上，而不是笼统地绑定到 Relying Party，从而仅凭持有 Token 不足以使用它。
• Access Token 的撤销是另一回事，且高度依赖实现——Access Token 在过期前可能一直有效。

Authelia 的客户端模型完整支持这些设计。在 internal/oidc/types.go 中可以看到RegisteredClient结构体包含DPoPBoundAccessTokens字段，且Client接口通过RefreshFlowScopeClient提供GetRefreshFlowIgnoreOriginalGrantedScopes方法，用于定制刷新流程中的 scope 行为——这些正是上述"发送者约束令牌"与"刷新流程细化"的工程化体现。

4.5 Claims 参数：跨所有流程的精细控制

除了 Implicit Flow 的单一变体之外，还有另一种方式可以让使用任何流程的客户端在 ID Token 中获得额外 Claims——这就是Claims 参数（Claims Parameter）。

Claims 参数允许请求特定的 Claim 出现在 ID Token 中，并且拥有一个额外的好处：支持对特定 Claim 的细粒度请求，而不是授予整个 Scope——后者可能附带一大堆对 Relying Party 毫无用处的 Claims。这在安全、隐私与可用性上都有显著影响。

此外，Claims 参数也是用来标注哪些元素是可选同意（optional to consent）的载体。大多数用户都见过那些询问"允许 Relying Party 访问哪些属性"的授权对话框——即使他们没有意识到这正是 Claims 参数在起作用。

Claims 参数的优势使其极具吸引力：你可以只请求openidscope，然后精确请求你需要的 Claims，并指定它们是在 UserInfo Endpoint 提供（更利于安全与隐私），还是在 ID Token 中提供。它强大到"不使用它简直是一种浪费"。

从源码看 Authelia 对 Claims 参数的实现

在 Authelia 的 internal/oidc/claims.go 中，NewClaimRequests函数负责解析授权请求表单中的claims参数：

func NewClaimRequests(form url.Values) (requests *ClaimsRequests, err error) { var raw string if raw = form.Get(FormParameterClaims); len(raw) == 0 { return nil, nil } // ...json.Unmarshal 解析，失败则返回 ErrInvalidRequest }

ClaimsRequests结构体（同文件定义）将参数拆分为两个映射：

type ClaimsRequests struct { IDToken map[string]*ClaimRequest `json:"id_token,omitempty"` UserInfo map[string]*ClaimRequest `json:"userinfo,omitempty"` }

这正是规范中 Claims 参数支持在id_token与userinfo两个位置请求 Claim 的体现。每个ClaimRequest支持三个字段：

type ClaimRequest struct { Essential bool `json:"essential"` Value any `json:"value,omitempty"` Values []any `json:"values,omitempty"` }

• essential：该 Claim 是否为必需；
• value/values：期望的特定值（可被用于校验，如请求特定sub）。

MatchesSubject与MatchesIssuer方法（同文件）会校验请求中的sub/iss期望值是否与当前实际值一致，不匹配则拒绝——这再次印证了"sub/iss是身份核心"的规范原则在实现层面的落地。

在验证层面，CustomClaimsStrategy.ValidateClaimsRequests会将请求的每个 Claim 与 scope→claim 映射表比对：如果请求的 Claim 需要某个 scope 而该客户端的注册 scope 中不包含它，就会返回ErrInvalidRequest，错误信息形如 "claims X require the 'Y' scope; but these scopes are absent from the client registration"。这意味着客户端不能绕过 scope 任意请求 Claim——Claims 参数授予的是"在已授权 scope 集合内的精细选择权"，而不是"无中生有的授权"。

从源码看 scope → claim 的映射

NewDefaultCustomClaimsStrategy（internal/oidc/claims.go）定义了标准 scope 与标准 Claim 的映射关系，例如：

• profilescope →name、given_name、family_name、middle_name、nickname、preferred_username、profile、picture、website、gender、birthdate、zoneinfo、locale、updated_at；
• emailscope →email、alt_emails、email_verified；
• phonescope →phone_number、phone_number_verified；
• addressscope →address；
• groupsscope →groups。

对应的标准 Claim 常量定义在 internal/oidc/const.go，例如ClaimSubject = "sub"、ClaimIssuer = "iss"、ClaimAudience = "aud"、ClaimEmail = "email"、ClaimPreferredUsername = "preferred_username"等，均与 IANA JWT Claim 注册表一致。

从源码看三种 Token 的注水差异

CustomClaimsStrategy的HydrateIDTokenClaims、HydrateAccessTokenClaims、HydrateUserInfoClaims三个方法（internal/oidc/claims.go）体现了第四节的规范语义：

• ID Token 注水：先复制原始 Claims（跳过jti、sid、at_hash、c_hash、exp、nonce、s_hash等特殊 OIDC Claim，也跳过标准 Claim），再根据claimsIDToken白名单填充 scope 相关 Claim（若为 implicit 流程则填充全部 scope Claim），最后处理 Claims 参数请求的 Claim。
• Access Token 注水：仅根据claimsAccessToken白名单填充 scope 相关 Claim，不处理 ID Token 专用逻辑。
• UserInfo 注水：填充全部 scope 相关 Claim、rat（requested at）Claim 以及 Claims 参数请求的 Claim。

这里claimsIDToken与claimsAccessToken正是来自配置中的 claims policy（详见下一节）。isClaimAllowed方法实现了白名单过滤：allowed == nil表示放行（如 UserInfo 场景），否则只有白名单内的 Claim 才会被填充。

从源码看 ID Token 的 aud 处理

hydrateClaimsAudience（internal/oidc/claims.go）保证 ID Token 的aud一定包含客户端 ID：若原始 Claims 中没有 audience，则设为[clientID]；若已有 audience 但不含 client ID，则追加。这与第二部分"ID Token 的aud必须是 Client ID"的规范要求完全吻合。

此外，CustomClaimsStrategy还支持id_token_audience_mode的experimental-merged模式（见 internal/oidc/const.go 中的IDTokenAudienceModeSpecification与IDTokenAudienceModeExperimentalMerged常量）：启用后通过MergeAccessTokenAudienceWithIDTokenAudience将 Access Token 的 audience 合并进 ID Token——这是 Authelia 针对某些"希望 ID Token 携带更丰富 aud"的集成场景提供的实验性扩展，默认的specification模式则严格遵循规范。

五、在 Authelia 中配置 Claims 策略：从原理到实战

理解了上述规范原理之后，来看看 Authelia 如何将它们工程化。Authelia 通过claims policies（Claims 策略）让管理员按客户端精细控制 Claim 的交付行为。相关配置结构定义在 internal/configuration/schema/identity_providers.go：

type IdentityProvidersOpenIDConnectClaimsPolicy struct { IDToken []string // 自动附加到 ID Token 的 Claims 列表 AccessToken []string // 自动附加到 Access Token 的 Claims 列表 IDTokenAudienceMode string // "specification"（默认）或 "experimental-merged" CustomClaims IdentityProvidersOpenIDConnectCustomClaims // 自定义 Claims }

客户端通过claims_policy字段引用某个策略，策略定义于identity_providers.oidc.claims_policies字典。仓库中的完整可运行示例位于 internal/configuration/test_resources/config_oidc_claims.yml，其核心片段如下：

identity_providers: oidc: scopes: example_scope: claims: - 'http://example.com/myclaim' claims_policies: default: custom_claims: authelia_admin: {} example_policy: custom_claims: example: name: 'http://example.com/myclaim' attribute: 'ioadmin' clients: - client_id: 'example_client' client_secret: '' public: true authorization_policy: 'one_factor' consent_mode: 'implicit' redirect_uris: - 'http://localhost:42420/3rdparty.UIL.Shell' scopes: - 'openid' - 'profile' - 'groups' - 'email' - 'example_scope' token_endpoint_auth_method: 'none' claims_policy: 'example_policy'

几个关键点：

1. 自定义 scope 与自定义 Claim 的配合：example_scope声明包含http://example.com/myclaim这一 Claim；example_policy通过custom_claims.example定义该 Claim 的name与attribute（attribute指向用户属性解析器中的ioadmin属性）。当客户端使用该 scope 时，策略必须能覆盖其每个 Claim——这对应 internal/configuration/schema/identity_providers.go 中IdentityProvidersOpenIDConnectScope注释所声明的约束："When this scope is used by a client the clients claim policy must satisfy every claim."
2. 自定义 Claim 的分发：custom_claims中的条目会经NewCustomClaimsStrategy汇入 scope→claim 映射（见 internal/oidc/claims.go 的NewCustomClaimsStrategy，它会把策略中的name→attribute注册进strategy.scopes），从而参与 ID Token、Access Token、UserInfo 三种注水流程。
3. 白名单控制：claims_policy中的id_token与access_token列表分别作为HydrateIDTokenClaims与HydrateAccessTokenClaims的白名单（claimsIDToken/claimsAccessToken）。留空（nil）时 ID Token/Access Token 默认不自动附加 scope Claim（区别于 UserInfo 的放行语义），这正是规范"ID Token 默认 Claim 集精简"的设计在配置层面的体现。

在运行 Authelia 后，可通过其 OpenID Connect Discovery 文档（/.well-known/openid-configuration，对应 internal/oidc/const.go 中的EndpointPathWellKnownOpenIDConfiguration）查看该 Issuer 支持的 scope 与 Claim 列表，以便 Relying Party 按第四节的原则正确消费 Claims。

六、结语：三者的"管弦乐"关系

回到开篇的比喻：Access Token 与 ID Token 的受众分野（第二部分）、iss+sub作为唯一身份锚点（第三部分）、Claims 交付渠道的规范语义（第四部分），三者相互咬合：

• 因为 Access Token 可能完全不透明、且只对特定端点有意义，所以身份识别必须依赖 ID Token 中的sub/iss；
• 因为sub/iss是静态的身份快照，而 UserInfo Endpoint 能返回最新数据，所以 scope 相关 Claim 默认应从 UserInfo 获取；
• 因为 Claims 参数能细粒度指定id_token或userinfo两个渠道，所以任何流程下的 Relying Party 都能在"精简 ID Token、保护隐私"与"即时可用"之间自由权衡。

理解并尊重这些规范语义，无论你是 Provider 实现者还是 Relying Party 集成者，都能在身份绑定、Token 校验与 Claim 消费上做出既安全又符合规范的设计决策。

附录：核心术语表

• Claim：关于某个实体（如 End-User、Resource Owner）被断言的某项信息，由 OpenID Connect 1.0 Core Terminology 与 Claims 章节详细定义。
• Access Token：传统上是不透明 Token（见 RFC 6749 第 1.4 节），也可能是专有格式或 RFC 9068 描述的 JWT 形式；用于访问资源。
• ID Token（Identity Token）：严格定义格式与内容的 JWT（见 OpenID Connect 1.0 Core 的 ID Token 章节），设计意图是唯一标识用户。
• JSON Web Token（JWT）：本文特指 compact 序列化形式。签名（而非加密）的 JWT 由三部分组成：头部（包含 Token 格式元数据）、正文（包含 Claims）、签名（前两部分的密码学哈希）。头部与正文都是经过 Base64 URL 编码的最小化 JSON 对象，详见 RFC 7519。
• Authorization Server：负责授权访问 Resource Server 上资源的角色。
• Resource Server：持有资源、需由 Resource Owner 授权并经 Authorization Server 验证才能访问的角色。
• Authorization Code Flow：在授权响应中返回短时效的 Authorization Code，客户端在 Token Endpoint 连同客户端认证要求交换所签发的 Token。
• Resource Owner：被请求信息的拥有者，通常是用户，但也可能是 Relying Party。
• End-User：人类参与者，是 Resource Owner 的一种类型。
• User Information Endpoint：由 OAuth 2.0 保护的端点，返回 Resource Owner（通常即用户）的信息。
• Introspection Endpoint：用于获取 Access Token 信息（无论其格式如何）的端点，见 RFC 7662。
• Revocation Endpoint：用于撤销 Access Token 与/或 Refresh Token 的端点，见 RFC 7009。
• Relying Party：依赖 OpenID Connect 1.0 Provider 处理授权流、依赖 Resource Owner 授予信息访问权的当事方。
• Scope：定义 Token 允许执行的特定动作或可访问的信息；在 OpenID Connect 1.0 中最常见的用途是定义 Token 可访问的 Claim 集合。
• Audience：Token（尤其是 JWT）的预期接收方，以单个字符串或字符串数组表示（URI 或其他唯一可识别名称），存于 JWT 的audClaim。
• Implicit Flow：直接在授权响应中返回所请求 Token 的流程，不以短时效 Code 换取 Token；因无客户端认证而传统上安全性较弱。
• Response Mode：授权端点响应授权请求的方式：query（重定向携带 URI 查询参数）、fragment（重定向携带 URI 片段参数）、form_post（以 POST 请求在请求体中携带响应）。
• Refresh Token Flow：在 Token Endpoint 用 Refresh Token 交换新 Token 的流程，新 Token 具有相同或收窄的安全特性。
• Refresh Token：通常完全不透明的 Token，可用于重新签发其他 Token。

【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia