OpenID Connect是什么（非常详细）

OpenID Connect（OIDC）是在 OAuth 2.0 框架之上的简单身份认证层，允许客户端应用基于授权服务器执行的身份验证来验证最终用户的身份，并以类似于 REST 方式的可互操作来获取有关最终用户的基本配置文件信息。

可互操作性（Interoperability）又称互用性，是指不同的计算机系统、网络、操作系统和应用程序一起工作并共享信息的能力。

OpenID Connect 允许所有类型的客户端（包括基于 Web 的客户端、移动客户端和 JavaScript 客户端）请求并接收有关经过身份验证的会话和最终用户的信息。规范套件是可扩展的，允许使用可选功能，例如身份数据加密、OpenID 提供器（Providers）的发现以及会话管理。

使用 OIDC，客户端应用可以请求 Identity Token，会和 Access Token 一同返回客户端应用。这个 Identity Token 可以被用来登录客户端应用程序，客户端应用还可以使用 Access Token 来访问 API 资源。

OpenID Connect 允许开发者验证跨网站和应用的用户，而无须拥有和管理密码文件（数据表）。OIDC 已经有很多的企业在使用，比如 Google 的账号认证授权体系、Microsoft 的账号体系等。当然，这些企业有的也是 OIDC 背后的推动者。

OIDC和OAuth 2.0的区别

OAuth 2.0 授权框架 [RFC6749] 和 OAuth 2.0 Bearer Token[RFC6750] 使用规范为第三方应用程序提供了获取和使用对 HTTP 资源的有限访问权限的通用框架。它们定义了获取和使用访问令牌访问资源的机制，但是没有定义提供身份信息的标准方法。

OAuth 2.0 不是身份认证（Authentication）协议，而是一个规范性的框架。这个规范没有强制性的约束力，不像 HTTP，它没有确切固定的格式，无法提供身份认证服务。OpenID Connect 在 OAuth 2.0 框架基础之上添加了一些组件来提供身份认证的能力，可以进行身份认证（Authentication），所以它兼容 OAuth 2.0，但同样没有非常固定的格式，没有人规定一定要怎么做，因为它们都只是一个规范性的约定。

OAuth 2.0 提供了 Access Token 来解决授权第三方客户端访问受保护资源的问题，OIDC 在这个基础上提供了 ID Token 来解决第三方客户端标识用户身份认证的问题。二者都是基于 JWT 技术的。

OIDC 的核心在于在 OAuth 2.0 的授权流程中一并提供用户的身份认证信息（ID Token）到第三方客户端，ID Token 使用 JWT 格式来包装，得益于 JWT（JSON Web Token）的自包含性、紧凑性以及防篡改机制，使得 ID Token 可以安全地传递给第三方客户端程序并且容易被验证。此外，还提供了 UserInfo 的接口，用于获取用户更完整的信息。

下表提供了 OIDC 使用的主要术语，并展示了术语与 OAuth 2.0 的对应关系。

表：OIDC 的主要术语及其与 OAuth 2.0 的对应关系
术语	释义	与 OAuth 2.0 对应术语
End User (EU)	表示一个人类用户（非系统程序）	资源拥有者 (Resource Owner)
Relying Party (RP)	依赖部分，用来代指 OAuth 2.0 中的受信任的客户端、身份认证和授权信息的消费方	客户端应用 (Client Application)
OpenID Provider (OP)	有能力提供 EU 认证的服务，用来为 RP 提供 EU 的身份认证信息	授权服务器和资源服务器 (Authorization Server / Resource Server)
ID Token	JWT 格式的数据，包含 EU 身份认证的信息	无
UserInfo Endpoint	用户信息接口（受 OAuth 2.0 保护），当 RP 使用 Access Token 访问时返回授权用户的信息，此接口必须使用 HTTPS	无

OIDC工作流程

从抽象的角度来看，OIDC 工作的流程主要有以下 5 个步骤：

RP 发送一个认证请求给 OP。
OP 对 EU 进行身份认证，然后提供授权。
OP 将生成 ID Token 和 Access Token，返回给 RP。
RP 使用 Access Token 发送请求到 UserInfo Endpoint，获取用户身份信息。
UserInfo Endpoint 返回给 RP 对应 EU 的用户信息（使用 Claims 承载）。

ID Token

ID Token 是一个安全令牌，是一个授权服务器提供的包含用户信息（由一组 Cliams 构成以及其他辅助的 Cliams）的 JWT 格式的数据结构，主要构成部分如下表所示。

表：ID Token的主要构成部分及其说明
字段	全称	释义	要求
iss	Issuer Identifier	提供认证信息者的唯一标识，一般是一个 HTTPS 的 URL（不包含 querystring 和 fragment 部分）	必需
sub	Subject Identifier	iss 提供的 EU 标识，在 iss 范围内唯一。它会被 RP 用来标识唯一的用户，最长为255个ASCII字符	必需
aud	Audience(s)	标识 ID Token 的受众，必须包含 OAuth 2.0 的 client_id	必需
exp	Expiration time	过期时间，超过此时间的 ID Token 会作废不再被验证通过	必需
iat	Issued At Time	JWT 的构建时间	必需
auth_time	Authentication Time	EU 完成认证的时间。如果 RP 发送 AuthN 请求的时候携带 max_age 的参数，则此 Claim 是必需的	可选
nonce	Nonce	RP 发送请求的时候提供的随机字符串，用来减缓重放攻击，也可以用来关联 ID Token 和 RP 本身的 Session 信息	可选
acr	Authentication Context Class Reference	表示一个认证上下文引用值，可以用来标识认证上下文类	可选
amr	Authentication Methods References	表示一组认证方法	可选
azp	Authorized party	结合 aud 使用。只有在被认证的一方和受众（aud）不一致时才使用此值，一般情况下很少使用	可选

ID Token 通常情况下还会包含其他的 Claims，毕竟上述 claim 中只有 sub 是和 EU 相关的，这在一般情况下是不够的，还必须有 EU 的用户名、头像等其他资料。

另外，ID Token 必须使用 JWS（JWT 的一种实现）进行签名、使用 JWE（JWT 的另一种实现，保证了安全性）加密，从而提供认证的完整性、不可否认性以及可选的保密性。

一个简单的 ID Token 示例如下：

{
  "iss": "https://server.example.com",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  "auth_time": 1311280969,
  "acr": "urn:mace:incommon:iap:silver"
}

OIDC的认证授权方式

OIDC 的授权认证方式主要有三种：

基于授权码（Authorization Code），及其扩展方式PKCE。
隐式（Implicit Code），已经不再推荐使用。
混合模式（Implicit Code + Authorization Code）。

具体的认证授权流程说明可查看官方文档（https://openid.net/specs/openid-connect-core -1_0.html）。

OpenID Connect是什么（非常详细）

OIDC和OAuth 2.0的区别

OIDC工作流程

ID Token

OIDC的认证授权方式

相关文章