尧图网页设计 
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两种完全不同的 Token2.1 设计初衷一个不透明一个必须是 JWT在 OpenID Connect 1.0 规范最初构思时Access Token 并没有统一的格式其格式完全由实现方决定。实际上Access Token 对于使用它的那一方如 Relying Party而言是完全不透明、无意义的。这一点非常重要它是理解 Access Token 设计意图的基石。与之形成鲜明对比的是ID Token 严格来说必须是一个 JSON Web TokenJWT。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 节audaudience标识 JWT 的目标接收方。下面两个示例分别是Authorization Code Flow下有效内容的 ID Token 与 Access Token参数如下Client IDK2LQE4XRC54N7C2F5ZLFAuthorized Audiencehttps://auth.example.com/api/oidc/introspectionScopesopenid 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可以得出几个关键结论ID Token 的aud是 Client ID。规范要求它必须可以附带额外值这清楚地表明Client 才是 ID Token 的预期接收方。Access Token 的aud不是 Client ID而是内省端点等资源地址。因为 Client 不是 Access Token 的预期接收方不应该用它来校验用户身份。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 实现都提供多种 Claimemail、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.翻译过来即是subsubject与ississuerClaim 组合使用是 RP 唯一可以信赖的 End-User 稳定标识符——sub在特定 Issuer 内对特定 End-User 必须本地唯一且永不重新分配因此对给定 End-User 而言唯一有保证的唯一标识符就是isssub的组合。而所有其他 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 为什么还存在它们主要有三个功能并非穷举但足以说明原则注册流程中的信息提示在 Registration Flow或某些 Identity Binding Flow即把sub/iss绑定到已有身份中向尚未登录的 Relying Party 提供有用的信息或提示例如预填表单。临时获取 Resource Owner 信息为已经绑定身份的 Relying Party 提供其不愿自行存储的 Resource Owner 信息例如在执行授权流后临时获取收货地址以完成一次购买。更新既有绑定身份的最新信息让 Relying Party 能够获得已绑定身份的 Resource Owner 的最新详情例如更新联系方式。四、Claims 可用性Scope 与 Claims Parameter4.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 EndpointID 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 的映射NewDefaultCustomClaimsStrategyinternal/oidc/claims.go定义了标准 scope 与标准 Claim 的映射关系例如profilescope →name、given_name、family_name、middle_name、nickname、preferred_username、profile、picture、website、gender、birthdate、zoneinfo、locale、updated_atemailscope →email、alt_emails、email_verifiedphonescope →phone_number、phone_number_verifiedaddressscope →addressgroupsscope →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、ratrequested atClaim 以及 Claims 参数请求的 Claim。这里claimsIDToken与claimsAccessToken正是来自配置中的 claims policy详见下一节。isClaimAllowed方法实现了白名单过滤allowed nil表示放行如 UserInfo 场景否则只有白名单内的 Claim 才会被填充。从源码看 ID Token 的 aud 处理hydrateClaimsAudienceinternal/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 policiesClaims 策略让管理员按客户端精细控制 Claim 的交付行为。相关配置结构定义在 internal/configuration/schema/identity_providers.gotype 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几个关键点自定义 scope 与自定义 Claim 的配合example_scope声明包含http://example.com/myclaim这一 Claimexample_policy通过custom_claims.example定义该 Claim 的name与attributeattribute指向用户属性解析器中的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.自定义 Claim 的分发custom_claims中的条目会经NewCustomClaimsStrategy汇入 scope→claim 映射见 internal/oidc/claims.go 的NewCustomClaimsStrategy它会把策略中的name→attribute注册进strategy.scopes从而参与 ID Token、Access Token、UserInfo 三种注水流程。白名单控制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 的受众分野第二部分、isssub作为唯一身份锚点第三部分、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 TokenIdentity Token严格定义格式与内容的 JWT见 OpenID Connect 1.0 Core 的 ID Token 章节设计意图是唯一标识用户。JSON Web TokenJWT本文特指 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 集合。AudienceToken尤其是 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Authelia 的 OpenID Connect 1.0 技术细节剖析：Access Token、ID Token、Claim 稳定性与 Claims 获取机制
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两种完全不同的 Token2.1 设计初衷一个不透明一个必须是 JWT在 OpenID Connect 1.0 规范最初构思时Access Token 并没有统一的格式其格式完全由实现方决定。实际上Access Token 对于使用它的那一方如 Relying Party而言是完全不透明、无意义的。这一点非常重要它是理解 Access Token 设计意图的基石。与之形成鲜明对比的是ID Token 严格来说必须是一个 JSON Web TokenJWT。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 节audaudience标识 JWT 的目标接收方。下面两个示例分别是Authorization Code Flow下有效内容的 ID Token 与 Access Token参数如下Client IDK2LQE4XRC54N7C2F5ZLFAuthorized Audiencehttps://auth.example.com/api/oidc/introspectionScopesopenid 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可以得出几个关键结论ID Token 的aud是 Client ID。规范要求它必须可以附带额外值这清楚地表明Client 才是 ID Token 的预期接收方。Access Token 的aud不是 Client ID而是内省端点等资源地址。因为 Client 不是 Access Token 的预期接收方不应该用它来校验用户身份。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 实现都提供多种 Claimemail、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.翻译过来即是subsubject与ississuerClaim 组合使用是 RP 唯一可以信赖的 End-User 稳定标识符——sub在特定 Issuer 内对特定 End-User 必须本地唯一且永不重新分配因此对给定 End-User 而言唯一有保证的唯一标识符就是isssub的组合。而所有其他 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 为什么还存在它们主要有三个功能并非穷举但足以说明原则注册流程中的信息提示在 Registration Flow或某些 Identity Binding Flow即把sub/iss绑定到已有身份中向尚未登录的 Relying Party 提供有用的信息或提示例如预填表单。临时获取 Resource Owner 信息为已经绑定身份的 Relying Party 提供其不愿自行存储的 Resource Owner 信息例如在执行授权流后临时获取收货地址以完成一次购买。更新既有绑定身份的最新信息让 Relying Party 能够获得已绑定身份的 Resource Owner 的最新详情例如更新联系方式。四、Claims 可用性Scope 与 Claims Parameter4.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 EndpointID 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 的映射NewDefaultCustomClaimsStrategyinternal/oidc/claims.go定义了标准 scope 与标准 Claim 的映射关系例如profilescope →name、given_name、family_name、middle_name、nickname、preferred_username、profile、picture、website、gender、birthdate、zoneinfo、locale、updated_atemailscope →email、alt_emails、email_verifiedphonescope →phone_number、phone_number_verifiedaddressscope →addressgroupsscope →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、ratrequested atClaim 以及 Claims 参数请求的 Claim。这里claimsIDToken与claimsAccessToken正是来自配置中的 claims policy详见下一节。isClaimAllowed方法实现了白名单过滤allowed nil表示放行如 UserInfo 场景否则只有白名单内的 Claim 才会被填充。从源码看 ID Token 的 aud 处理hydrateClaimsAudienceinternal/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 policiesClaims 策略让管理员按客户端精细控制 Claim 的交付行为。相关配置结构定义在 internal/configuration/schema/identity_providers.gotype 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几个关键点自定义 scope 与自定义 Claim 的配合example_scope声明包含http://example.com/myclaim这一 Claimexample_policy通过custom_claims.example定义该 Claim 的name与attributeattribute指向用户属性解析器中的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.自定义 Claim 的分发custom_claims中的条目会经NewCustomClaimsStrategy汇入 scope→claim 映射见 internal/oidc/claims.go 的NewCustomClaimsStrategy它会把策略中的name→attribute注册进strategy.scopes从而参与 ID Token、Access Token、UserInfo 三种注水流程。白名单控制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 的受众分野第二部分、isssub作为唯一身份锚点第三部分、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 TokenIdentity Token严格定义格式与内容的 JWT见 OpenID Connect 1.0 Core 的 ID Token 章节设计意图是唯一标识用户。JSON Web TokenJWT本文特指 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 集合。AudienceToken尤其是 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考