探索 OpenID Connect 配置：关键字段及其用途
探索 OpenID Connect 配置的关键字段和实际应用。
Developer
在当今的数字世界中，身份验证已成为保护网站和应用程序的核心组件。OpenID Connect (OIDC) 是基于 OAuth 2.0 协议构建的身份验证层，提供了一种标准且简单的方式来验证身份。
然而，正确地集成 OIDC 可能会令初学者感到望而生畏。一个好的起点通常是 OIDC 配置文件，通常可以在 {authServerUrl}/.well-known/openid-configuration URL 找到，其中包含了实施 OIDC 服务所需的所有详细信息。
本指南旨在阐明该配置中的关键字段，帮助开发人员理解其重要性和实际应用，从而更好地将 OIDC 集成到他们的项目中。
分析 OIDC 配置字段
OIDC 配置是一个类似于以下的 JSON 文件：
接下来，我们将深入探讨一些关键字段。
authorization_endpoint
在集成 OIDC 服务时，第一步通常涉及在应用程序中处理用户登录请求。此过程包括将用户重定向到授权服务器的 authorization_endpoint。此端点是发送授权请求的服务器地址，引导用户到登录页面进行身份验证。
在向 authorization_endpoint 发起请求时，必须为每个授权配置额外的查询参数：
response_type: 指定返回的授权类型。通常包括“code”（用于授权码流程）、“token”（用于隐式流程）以及“id_token token”或“code id_token”（用于混合流程），这些可以在 OIDC 配置的response_types_supported字段中找到。client_id: 在应用注册时，由授权服务器分配给应用程序的唯一标识符。授权服务器使用此 ID 识别发起请求的客户端应用程序。scope: 定义所请求的访问范围，指定可访问的资源或用户信息。常见的范围包括“openid”（强制要求）、“profile”和“email”等。你可以在 OIDC 配置的scopes_supported字段中找到受支持的范围；不同的范围应该用空格分隔开来。redirect_uri: 登录或授权后，授权服务器将用户重定向回应用程序提供的 URI。此 URI 必须严格匹配应用程序注册时提供的 URI。state: 一个随机生成的字符串，用于保护客户端免受跨站请求伪造攻击。必须确保授权请求和回调之间的 state 一致性以确保安全。
这些参数允许开发人员精确控制 OIDC 授权请求的行为，确保它们既安全又符合应用程序的需求。
在完成向 authorization_endpoint 的请求并通过身份验证后，用户将被重定向到指定的 redirect_uri，其中将包含一个非常关键的查询参数——code。这个授权码是由授权服务器提供的，是用户通过认证并授权应用程序访问其在授权服务器上的信息的结果。
token_endpoint
token_endpoint 是授权服务器用于将上述授权码兑换为访问令牌和刷新令牌的服务器端点。在 OAuth 2.0 授权码流程中，这一步至关重要，因为它涉及将获得的授权码转化为实际的访问令牌，应用程序可以使用该令牌访问用户的受保护资源。
下面是如何实现将授权码交换为访问令牌的示例（注意，此示例使用 client_secret_post 身份验证 方法。对于其他支持的身份验证方法，请参考后面的
token_endpoint_auth_methods_supported在这段代码中，我们首先使用 POST 方法向 token_endpoint 发送请求。内容类型设置为 application/x-www-form-urlencoded，这是大多数授权服务器所要求的。请求体包括以下参数：
- code: 从授权服务器获得的授权码，该授权码通过
redirectUri返回，用户在完成授权后获得。 - redirect_uri: 用于获取授权码的相同重定向 URI，用于验证请求的合法性。
- client_id: 应用程序的客户端标识符，用于标识发出请求的应用程序。
- client_secret: 应用程序的客户端密钥，用于验证应用的身份。
- grant_type: 指定授权类型，这里使用
"authorization_code"，表示通过授权码获取访问令牌。
此函数是异步执行的，并返回包含访问令牌的 JSON 对象，应用程序可以使用该访问令牌请求用户数据或执行其他操作。
userinfo_endpoint
userinfo_endpoint 是由授权服务器用于获取已认证用户的详细信息的服务器端点。在用户成功授权并通过 token_endpoint 获取访问令牌后，应用程序可以请求该端点以访问用户的配置文件信息，如用户名和电子邮件地址。具体获取的信息取决于用户在身份验证请求中指定的 scope。
在这个函数中，我们首先使用 GET 方法请求 userinfo_endpoint，在请求头中包含 token_type 和 accessToken 组成的 Authorization 字段。这是根据 OAuth 2.0 规范的标准操作，确保安全地获取用户信息。此外，通过访问令牌访问的用户信息范围完全取决于用户在授权发起时采用的 scope 参数值。例如，如果使用 email 范围，响应中应包含用户的电子邮件地址。
issuer & jwks_uri
issuer 标识授权服务器的 URL，而 jwks_uri 提供了用于获取 JSON Web Key Set (JWKS) 的 URI，JWKS 是用于验证 JWT 签名的公钥集。验证 JWT 的 issuer 和签名是确保令牌安全的基本步骤，但在实际情况下，通常还包括检查令牌的有效期、受众、授权范围以及其他重要字段。
以下代码主要演示了如何将 issuer 和 jwks_uri 一起使用来验证 JWT：
scopes_supported & claims_supported
claims_supported 和 scopes_supported 字段声明了授权服务器支持的用户属性（声明）和访问范围（范围）。它们帮助客户端了解授权服务器支持的用户属性和访问范围，使客户端能够有效地构建授权请求并解析响应。
在构建授权请求时，客户端可以根据应用程序的需要指定所需的 scope。Scope 定义了客户端请求访问的资源和操作，如 openid、email、profile 等。
需要注意的是，每个授权请求中可以访问的特定声明因身份验证请求开始时指定的范围值而异。例如，email 范围授予对用户电子邮件地址的访问权限，而 phone 范围则提供对其电话号码的访问。因此，客户端在构建授权请求时应仔细选择相应的范围，以匹配应用程序的需求，确保能够检索到必要的用户属性：
token_endpoint_auth_methods_supported
token_endpoint_auth_methods_supported在使用 token endpoint 进行身份验证时，常见的身份验证方法包括 client_secret_post、client_secret_basic 和 client_secret_jwt。
-
client_secret_post: 客户端使用其客户端标识符和客户端密钥构建一个表单编码的请求体，并将其作为请求体的一部分发送。我们已经在上面的token_endpoint部分中看到了这种方法的一个示例。 -
client_secret_basic: 客户端使用其客户端标识符和客户端密钥构建基本身份验证头，然后将其添加到请求头中。
client_secret_jwt: 客户端使用 JWT (JSON Web Token) 作为客户端断言进行身份验证。这个 JWT 包含客户端标识符和一些额外的元数据，并使用客户端密钥签名。在接收到请求后，授权服务器通过验证 JWT 的签名来验证客户端的身份。
在实际应用中，客户端需要根据授权服务器支持的方法选择适当的身份验证方法，并确保正确地将身份验证信息添加到请求中，以安全地将授权码兑换为访问令 牌。
总结
我们已经探索了 OIDC 配置中的关键字段，重点关注了它们的用途和应用。理解这些细节将增强你对 OpenID Connect 的理解，使你能够更有效地集成和利用它的功能应用于你的项目中。掌握了这些知识后，你可以更好地利用 OIDC 的全部潜力，为用户提供更安全和高效的身份验证解决方案。
Logto 是一个构建在 OIDC 之上的身份验证服务，它提供了一个全面的多语言 SDK 套件，并附有众多集成教程，使你能够在几分钟内将 OAuth / OIDC 登录无缝集成到你的应用程序中。如果你正在寻找一个可靠且易于使用的 OIDC 服务，今天就试试 Logto 吧！