【发布时间】：2017-12-27 18:17:11
【问题描述】：
我们目前正在组织内实施 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，在他们不知情的情况下冒充用户，这就是为什么我们需要一种方法来确保用户已通过身份验证。
我觉得我在这里错过了一块拼图。这样做的“正确”方法是什么？
【问题讨论】：
-
在选择访问令牌或 id_token 时，我会说使用
id_token。正确使用目标受众列表，以及令牌中所需的组/角色信息（我不知道 gluu 是否允许您配置它），当然还有分离验证，使用 id_token 没有任何问题。它是一个包含身份声明并且可以传递的令牌，并且应该可以使用 OP 对其进行更新。 -
@fiddur 感谢您的回复。这种方法的问题是前端客户端可能不（并且可能不应该）知道下游涉及哪些其他服务，因此无法正确设置受众，除非我们有一些内部应用程序的普遍受众......
-
如果 REST 服务使用 Client_Creds 流连接到数据服务，那么为什么需要将用户信息传递给数据服务，如果需要传递该数据以获取与用户相关的数据或类似的用户 ID/用户名在技术上输入到发送到数据服务的查询，在这种情况下，用户 ID/名称应作为数据传递给资源服务器（数据服务）。如果我错过了什么，请告诉我
-
另外，ID_token 和 access_token 是不同的。
-
@dvsakgec 我们正在使用客户端凭据流，因此传递了 client_id 和 client_secret。这些应用程序都无法访问用户的凭据（IDP、Gluu 除外），因此即使我们想要（我们没有）我们也不能使用资源所有者流程将用户凭据与客户端一起传递证书。用户身份验证的证明需要传递到数据服务中，以确保 a) 用户确实委派了对该进程的访问权限，并且 b) 用户实际上应该有权读取/写入该数据（或数据的子集）跨度>
标签： single-sign-on openid-connect oauth2 gluu