使用 openid connect 作为 SSO 用于多个应用程序

Posted 2023-03-27

【中文标题】使用 openid connect 作为 SSO 用于多个应用程序

【英文标题】：Use openid connect as SSO for multiple applications

【发布时间】：2019-01-20 07:15:42

【问题描述】：

我正在尝试使用 openid connect 为我的应用程序创建 SSO。

基本上我们有一个 API 层，不同的应用程序（客户端）将使用该层的服务。

首先，我们为每个不同的应用添加了 OAuth2.0 授权；对于身份验证，我们目前正在使用我们自己的数据库 (IDP)

我们希望最终用户在此流程中拥有单点登录体验。 为此，我们在已构建的 OAuth 流程之上添加了 openid。

Web 服务器具有标准的 oauth + openid 实现，并具有以下功能

显式流 隐式流 密码授予

添加 openid 连接后，服务器现在也可以发送 id_token (jwt)，具体取决于范围和请求类型

注册了两个客户端（C1 & C2）

第 1 步：C1 遵循显式流程并使用响应类型作为代码，因此当用户 (U1) 访问 C1 时，它会被重定向到 U1 输入凭据的身份验证服务器。

第2步：授权服务器验证凭据并提示用户同意，确认将代码发送到C1的redirect_uri

步骤3：C1然后请求token，服务器给出access_token和id_token；访问令牌被持久化在数据库中

第 4 步：U1 现在需要访问 C2

问题：

C2 在无需用户再次登录的情况下从 api 服务器获取访问令牌的最佳方式/实践是什么。 如果 C1 通过本地存储或任何其他方式将 jwt id_token 传递给 C2，一种可能的方法是将 id_token 交换为 this 之后的 access_token。 如果我们采用上述方法，是否只需验证 id_token 并发出 access_token 就足够了，还是应该添加任何其他检查 任何其他方法。

谢谢

【参考方案1】：

流程的选择取决于客户的类型。例如，客户端可以是本机应用程序，它可以使用授权代码流（我猜您将 Explicit Flow 称为此流）。或仅在浏览器上运行的 javascript 应用程序。

解决方案 - 基于会话 cookie 的 SSO

在 OAuth 2.0（包括 OpenID Connect）中，最终用户（例如：-您的示例中的 U1）身份验证通过浏览器交互进行。在这个过程中，通常授权服务器会建立一个会话。此会话所做的是保留对先前经过身份验证的用户的引用。例如，这允许用户访问 IDP 并更新在那里满足的用户（如果您的身份提供者支持的话）。

现在，如果两个应用程序使用相同的浏览器（例如：Microsoft Edge）在 OpenID Connect 的授权请求中显示登录屏幕，您的授权服务器可以检查浏览器中存在的会话 cookie。如果是这种情况，授权服务器可以跳过登录屏幕并响应相关内容。以下是新登录的示例场景

C1 统计并发送授权请求 授权服务器接收请求并检查会话 cookie。 由于这是一个全新的开始，不存在 cookie，因此存在登录 用户U1登录 授权服务器发送响应和C1完成令牌获取 C2启动并发送授权请求 授权服务器接收请求并检查会话 cookie。 由于我们使用的是同一个浏览器，会话 cookie 存在并且相关用户被识别为 U1 授权服务器发送响应和C2完成令牌获取

现在 C1 和 C2 都有 U1 用户登录。这是基于浏览器的 SSO。

【参考方案2】：

如果这些客户端是 Web 应用程序，由于某些原因，最好和推荐使用的流是隐式流：

如果与混合流相比，这种情况下它是安全的，因为混合流与clinet共享一个密钥，客户端必须保留它，这个密钥用于生成acces_tokens，另一方面隐式流直接向客户端提供一个生命周期短的访问令牌，因此最好是提供一个生命周期短的 access_token，而不是一个生命周期长的授权密钥，可用于生成令牌。

SSO（单点登录）将在共享同一 STS 服务器的客户端之间完美运行，因此 C2 无需身份验证即可拥有 access_token，步骤如下：

C1 验证并获取 id-token 和 access_token

为此活动会话创建会话 cookie

C2点击登录会直接获取access_token，无需认证，因为浏览器会发送一个从C1认证创建的有效cookie

【讨论】：

如果访问令牌嵌入了客户端 ID，并且服务器使用客户端 ID 来控制访问，那么上述解决方案将起作用。