OpenID Connect 是什么？和 OAuth 有哪些异同？

因为工作关系，我需要给一个业务网站配置一个 SSO，我一看，这个业务网站只支持 SAML 和 OpenID Connect，也即 OIDC。其实早就听说过这个词，但是没有仔细了解过。所以，特来学习一下到底什么是 OIDC。

一、什么是 OpenID Connect？

在这里插入图片描述

OpenID Connect（OIDC）是一个基于Internet的标准身份验证协议，它建立在OAuth 2.0授权框架之上。通过OIDC，第三方应用可以安全地认证用户，并获取其基本的个人信息，同时保证用户的登录过程安全和简洁。

发明时间

OpenID Connect 1.0 是在2014年发布的。它由OpenID Foundation推动，这是一个非营利国际标准组织，旨在推动身份认证的开放标准。

发明原因

OpenID Connect的发明有几个关键的动机和目的：

简化用户体验：

OpenID Connect允许用户使用单一的身份认证信息（如Google账户或Facebook账户）登录多个应用。这种“单点登录”（SSO）功能简化了用户的登录体验，减少了需要记忆多个用户名和密码的负担。

安全性和隐私：

OAuth 2.0 是一个非常成功的授权框架，但它本身并不处理身份认证。OpenID Connect 在 OAuth 2.0 的基础上添加了身份验证层，提高了安全性。它使用 ID Tokens 和数字签名技术来确保身份信息的安全传输和验证。

互操作性：

随着互联网服务的增加，需要一个标准化的方法来处理跨域的身份验证和授权。OpenID Connect 作为一个开放标准，支持广泛的互操作性，允许不同系统和服务之间的无缝集成。

适应现代应用架构：

随着移动设备和单页应用（SPA）的兴起，需要一种可以在这些现代应用架构中高效工作的身份验证方法。OpenID Connect 支持这些应用的身份验证需求，允许令牌和用户信息的安全传输。
通过满足这些需求，OpenID Connect 成为了现代互联网应用广泛采用的身份验证标准，被全球许多大型技术公司和服务所支持。

二、与 OAuth 2.0 的异同

从上，我们已经知道 OpenID Connect 是建立在 OAuth 2.0 之上的，那么 OpenID Connect 与 OAuth 2.0 到底有什么异同？

主要异同

目的:

OAuth 2.0：主要用于授权，允许应用访问用户在另一个服务上的资源，而不需要向应用暴露用户的用户名和密码。
OpenID Connect：在OAuth 2.0的基础上增加了身份验证。它允许客户端验证用户的身份并获取基本的用户个人信息。

ID令牌:

OpenID Connect 引入了ID令牌（ID Token），这是一个JSON Web Token（JWT），包含了关于用户的信息，可以被客户端用来验证用户身份。
OAuth 2.0 不提供 ID 令牌，它关注于访问令牌（Access Token）来获取资源。

用户信息:

OpenID Connect 提供了一个标准的端点（UserInfo Endpoint），客户端可以使用Access Token从该端点获取用户信息。
OAuth 2.0 标准本身并不定义如何获取用户信息，这通常由实现者自行扩展。

将OAuth 2.0 IdP升级为OpenID Connect

如果你已有一个实现了OAuth 2.0的身份提供者（IdP），你不能直接将其作为OpenID Connect提供者使用，因为缺少了处理ID令牌和UserInfo端点的功能。要进行升级，通常需要进行以下改动：

ID令牌的生成：你需要在身份验证流程中添加生成JWT格式的ID令牌的功能，这包括对用户身份的验证以及必要的加密和签名过程。

UserInfo端点：需要实现一个端点，通过此端点，客户端可以使用Access Token来获取用户的详细信息。

配置信息：OpenID Connect要求提供一个发现文档（通常是在.well-known/openid-configuration的URL下），描述你的OpenID Connect服务的相关元数据。

三、OpenID Connect 的基本流程

OpenID Connect (OIDC) 的验证流程在很多方面与 OAuth 2.0 的流程相似，但增加了一些关键的步骤和元素以支持身份验证。这包括了ID令牌（ID Token）的引入，这是一个基于JSON Web Token (JWT) 的令牌，用于确认用户身份。

OpenID Connect 的基本流程：

用户重定向：
- 应用将用户的浏览器重定向到 IdP 的授权端点（Authorization Endpoint），与 OAuth 2.0 类似。不同的是，OIDC在重定向时需要明确请求openid作为作用域（scope）之一，这表示正在进行一个OpenID Connect请求。
用户登录和授权：
- 用户在 IdP 的页面上进行身份验证（如果尚未登录）并授权应用访问其信息。这一步同OAuth 2.0。
IdP 返回授权码：
- IdP 将用户浏览器重定向回应用的回调地址（Callback URL），并附带一个授权码（Authorization Code）。这与OAuth 2.0 相同。
交换授权码：
- 应用服务器使用授权码，通过向 IdP 的令牌端点（Token Endpoint）发送请求来交换访问令牌（Access Token）和ID令牌。这一步超出了OAuth 2.0的标准范畴，因为它涉及到了ID令牌的获取。
验证ID令牌：
- 应用服务器需要验证ID令牌的有效性，包括验证签名和声明，如发行者、用户、令牌的有效时间等。
获取用户信息：
- 应用可以使用访问令牌向用户信息端点（UserInfo Endpoint）发送请求，以获取更多用户信息。这一步是OpenID Connect特有的，用于获取标准化的用户个人信息。

至关重要的 API 端点

授权端点（Authorization Endpoint）：
- 这是启动OIDC认证流程的地方，用于接收授权请求并对用户进行身份验证和授权。
令牌端点（Token Endpoint）：
- 这个端点用于交换授权码以获取Access Token和ID Token。此步骤是服务器到服务器的通信，保证了安全性。
用户信息端点（UserInfo Endpoint）：
- 提供标准化的API，应用可以通过此端点使用Access Token获取用户的详细信息。
JWKS端点（JSON Web Key Set Endpoint）：
- 这是一个提供公开密钥的端点，客户端可以使用这些密钥来验证ID Token的签名。
发现文档（Discovery Document）：
- 通常位于.well-known/openid-configuration，这个文档包含了OIDC服务的所有相关元数据和端点信息。

通过实现这些核心功能和端点，你的身份提供者就可以支持OpenID Connect协议了，从而不仅能授权用户访问资源，还能验证其身份。

四、图解分析

1. response_type=code

在这里插入图片描述
如果您了解 OAuth 2.0，就会对这幅图充满了熟悉感。因为这就完全是 OAuth 2.0 的经典授权流程，类型是 authorization_code，唯一有区别的是，最后一步，同时返回了 id token（JWT）和 access token，两种类型。同样，这也是一种比较典型的 OIDC 交互流程。在 scope 参数包含 openid 的时候，会返回两者，如果 scope 参数只包含 token 的话，则完全退化成了 OAuth 2.0。

2. response_type=token

在这里插入图片描述
当 response_type=token 的时候，也是让人深感熟悉的，这恰恰就是 OAuth 2.0 的另一种场景，就是 implicit 流程。等于也退化成了 OAuth 2.0。

3. response_type=id_token

在这里插入图片描述

这种流程几乎和 OAuth 2.0 的 implicit 的流程一致。但是最后返回的却不是 access token 而是 ID Token。这就是 OIDC 独有的一种流程了。而这大概也是 OIDC 强调的，不同于 OAuth 2.0 只关注授权，OIDC 还关注验证的原因。ID Token 本质上不包含授权信息，只包含身份验证信息，这个信息被 JWT token 携带，服务提供商 SP 是可以通过解析 JWT 来验证用户的身份的。是一种比 OAuth 2.0 要轻便很多的流程，如果你的 SP 压根不需要访问用户的授权信息的话，那么使用此流程便足够了。

4. response_type=id_token token

在这里插入图片描述
这种流程就更容易理解了，无非就是上面两种类型的整合。

5. response_type=code id_token

在这里插入图片描述
感觉这就是在玩一种排列组合游戏了，这种情况下，在第三步，返回了身份验证信息的时候，授权 code 也给出了。但是服务器没有给出 access token，SP 可以进一步去获取 access token，也可以不去获取，直接使用 ID Token。

6. 其他

还有几种类型，我甚至觉得有点荒诞，大家自己看图理解一下：

在这里插入图片描述

五、总结评价

从上面的简述分析和实例分析中，我们可以看到 OpenID Connect 是对 OAuth 2.0 的一种扩展和补充。其 response_type 参数的自由组合，给实施者提供了极大的灵活性，能做到按需实现，或者按需调用。不过这种极大的灵活性，也出现了很多看起来甚至有点荒诞的组合。这种设计在笔者的认知里是不够优雅的，不应该给出这种近乎无聊的选择。当然这也是本人比较初步的判断。

另外，另我担忧的是，其安全性到底如何，暂时没有时间去深入探究其 Threat Model 和安全白皮书。因为早年看到一些安全专家对 OAuth 2.0 的驳斥，我一直对 OAuth 2.0 的安全抱有担忧。尤其是我亲眼看过很多程序员不负责任的实现后，更加担心。OAuth 2.0 是极其脆弱的一套鉴权方式，其安全性大部分押宝在 HTTPS 之上，以至于 OpenSSL 出现了 heart bleed 的时候，无数站长颤抖。

不过用在不太重要的系统鉴权之上，还是很方便的。大家自己权衡。