我们目前正在组织内部实施SSO，已经决定使用OpenId Connect作为我们的身份验证协议（特别是使用Gluu）。
我们遇到的问题是将一个我们可以证明已经过身份验证的身份传递给一系列后端服务。我已经看到人们通过了id_token，但据我所知，这不是id_token的意图，而是真正意味着初始客户端要消费。
假设我们有一个Angular Application调用相关的REST服务，他们称之为某种数据服务。目前，angular app会将未经身份验证的用户重定向到Gluu进行登录，并提供id_token和access_token。
Gluu的实现是提供一个不透明的access_token。因此，当我们将该令牌从Angular应用程序传递到REST服务时，我们将返回Gluu来验证令牌，提取与之关联的用户信息（基于OpenId使用的范围）和客户端信息。这一切都适用于第一跳。
从REST服务连接到数据服务时出现问题。使用client_credential流，REST服务调用Gluu和数据服务的范围以获取新的访问令牌。但是，我发现无法更换原始令牌，因为新令牌会保留原始用户的声明。
我已经看过人们说的建议，并且＃34;你好在一个受信任的域内，所以只需传递用户ID并相信他们已经过身份验证。＆＃34;这对我们不起作用。我们以前使用过HMAC方案，团队正在传递从未经过身份验证的用户标识，在他们不知情的情况下冒充用户，这就是为什么我们需要一种方法来确保用户已经过身份验证。
我觉得我在这里错过了一块拼图。什么是＆＃34;权利＆＃34;这样做的方法？
答案 0 :(得分：0)
请不要传递id_token。 OpenID Connect规范声明id_token用于客户端应用程序。我已经看到这个问题以两种方式解决了
1）要求客户端应用程序请求所有必需的下游范围，以便其访问令牌适用于所有服务，并且受众包含正确的服务。在你的情况下这可能是不可能的，但我会说这将是最简单的（也许不是最好的）方法。
2）我对GLUU一无所知，但OAuth 2.0规范讨论的extension grants可能对您的情况有用。这只是意味着根据规范，您可以定义自己的授权，而不是代码＆＃39;，＆＃39;密码＆＃39;和隐含的＆＃39;我建议您实施自定义授权。您可以定义用于验证用户身份的自定义信息。还有另一个名为IdentityServer的OAuth 2.0 / OpenID Connect框架。即使它不是GLUU，我认为你将能够关注这篇关于扩展授权的文章，因为在一天结束时，GLUU和IdentityServer遵循一个定义良好的协议。本文展示了扩展授权如何解决您正确委派身份验证的特定问题。看看here。我希望你能用GLUU实现类似的东西。