1

我们目前正在我们的组织内实施 SSO，已决定使用 OpenId Connect 作为我们的身份验证协议（特别是使用 Gluu）。

我们遇到的问题是将我们可以证明已经过身份验证的身份传递给后端服务链。我见过人们传递 id_token，但据我了解，这实际上不是 id_token 的意图，而是仅用于初始客户端使用。

假设我们有一个 Angular 应用程序调用相关的 REST 服务，他们称之为某种数据服务。目前，Angular 应用程序会将未经身份验证的用户重定向到 Gluu 进行登录，并提供 id_token 和 access_token。

Gluu 的实现是提供一个不透明的 access_token。因此，当我们将该令牌从 Angular 应用程序传递到 REST 服务时，我们返回到 Gluu 以验证该令牌，提取与其关联的用户信息（基于与 OpenId 一起使用的范围）和客户端信息。这一切都适用于第一跳。

从 REST 服务连接到数据服务时会出现问题。使用 client_credential 流，REST 服务调用具有数据服务范围的 Gluu 以获取新的访问令牌。但是，我发现无法将原始令牌交换为保留原始用户声明的新令牌。

我看到有人说，“你在一个受信任的域中，所以只需传递用户 ID 并相信他们已经过身份验证。” 这对我们不起作用。我们之前使用的是 HMAC 方案，团队在传递从未经过身份验证的用户 ID，在他们不知情的情况下冒充用户，这就是为什么我们需要一种方法来确保用户已通过身份验证。

我觉得我在这里错过了一块拼图。这样做的“正确”方法是什么？

4

1 回答 1

0

请不要传递 id_token。OpenID Connect 规范声明 id_token 用于客户端应用程序。我已经看到这个问题有两种解决方法

  1. 要求客户端应用程序请求所有必需的下游范围，以便其访问令牌适用于所有服务，并且受众包含正确的服务。在您的情况下这可能是不可能的，但我会说这将是最简单（也许不是最好）的方法。

  2. 我对 GLUU 一无所知，但 OAuth 2.0 规范谈到了扩展授权，这在您的情况下可能很有用。这只是意味着根据规范，您可以定义自己的授权，而不是“代码”、“密码”和“隐式”。我建议您实施自定义授权。您可以为验证用户定义一条自定义信息。我使用了另一个名为 IdentityServer 的 OAuth 2.0/OpenID Connect 框架。尽管它不是 GLUU，但我认为您将能够关注这篇关于扩展授权的文章，因为最终 GLUU 和 IdentityServer 都遵循一个定义明确的协议。本文展示了扩展授权如何解决您正确委派身份验证的具体问题。看看这里. 我希望你可以用 GLUU 实现类似的东西。

于 2017-12-27T10:17:11.613 回答