OpenID Connect：使用id_token作为access_token可以吗？

在我的工作中的一个应用程序中，我们正在考虑为所有用例（包括身份验证和授权）使用id_token。解决方案正在从头开始研发。目前没有任何资源的消费者，我们可以修改资源以使用id_token。我对openid_connect和oauth 2.0的概念有点新鲜。是否有使用id_token具有所有访问细节的问题？OpenID Connect：使用id_token作为access_token可以吗？

来源

2017-08-08 Guru

如果应用程序需要只是为了验证用户身份，然后让他们用所有他们可以访问的功能访问其后端，它更容易使用只是一个ID令牌和检查基于用户名或角色的访问权限。仅使用ID令牌时，您还可以接受来自不同OAuth2提供者的ID令牌。

访问令牌是部分访问委托有用的 - 当用户委派他们的一些权限的另一个应用程序。例如，如果我创建的应用程序要求其用户对其GMail的只读访问权限，则该应用程序可以在不允许访问该用户的任何其他Google资源的情况下访问该应用程序。

如果您想为简单的客户端应用程序及其后端使用访问令牌，那么您的客户端应用程序将要求它可能使用的所有OAuth2范围，然后查看从它获得的访问令牌中返回的范围OAuth2服务器。

所以，如果你想创建你的后台API只是它的前端，并且不打算将它开到其他应用程序，它更容易使用的只是ID令牌。如果您发现需要访问令牌，则可以稍后开始使用它们。

您还可以考虑根据您提供的ID令牌发布您自己的令牌（JWT），并提供您需要的所有验证和授权信息，这样您的后端无需在每个API访问权限上获取用户的安全数据。

来源

2017-08-08 13:11:04

谢谢Jan for。这种情况正是使用gmail和其他资源的例子提到的。我们的生态系统中存在类似的资源，可通过除我们之外的其他应用访关键是可以设计资源只依靠id_token;以及附加到id_token的细粒度级别权限/访问权限。我试图回答的另一个问题是 - 拥有两个令牌的优势是什么？为什么不能在一个单一的标记中合并起始？除了存储的数据种类之外，id_token和access_token之间是否有任何fundmtl差异？ – Guru

ID标记是在OpenID Connect中引入的，用于身份验证。如果你想授权访问权限，访问令牌就是为此设计的 - 用户同意将他们的一些权利传递给应用程序。如果按照它包含范围的方式（与访问令牌相同的方式）构造ID令牌，那么您正在创建一个新的协议。您不需要在应用程序之间传递ID令牌 - 它们只应证明用户的身份。如果一个应用程序A调用应用程序B，则A是调用者，而不是最初调用A的用户。 –

谢谢@Ján回复。 “你应该不需要在应用程序之间传递ID令牌 - ** _他们_ **应该只证明用户的身份” - 当你说他们时 - 应用程序B（资源服务器）是否需要使用access_token来证明用户的身份？如果是，那么假设access_token不具有身份信息，那么该怎么做。 – Guru

我建议以下的OIDC规范的设计（即使用的access_token而不是id_token的资源服务器授权），以防止开放自己最多的安全漏洞。

这里有一个很好的讨论有关使用id_token作为的access_token：https://github.com/IdentityServer/IdentityServer3/issues/2015#issuecomment-147527823

该规范是专门针对ID令牌在客户端使用，并在API来使用的访问令牌。我相信你能想出一些替代协议重新使用ID令牌，但OAuth2用户和OIDC 只是没有进化的方式。我敢肯定，如果他们都是从划伤的设计，他们会看起来不同。

至于“是它的安全ID令牌传递到后端” - 不知道。我真的没有仔细研究针对它的攻击，或者如何操纵或愚弄它。规范作者做这样的事情，这就是为什么我们倾向于坚持自己的领先，因为他们已经花了很多，然后我有。

问题，为什么要使用id_token而不是access_token？获得真正的access_token很容易，所以为什么要违背规范？

来源

2017-08-08 13:41:22 sdoxsee

谢谢@sdoxsee。实际上，所使用的IDP是供应商产品，不允许在access_token中添加自定义声明。但它确实允许定制id_token。另外，我浏览了您分享的链接。我完全理解了id_token和access_token背后的概念。唯一的困惑是，有两个令牌但有分离的问题有什么显着的优势。还有，你提到了安全漏洞 - 我无法从你分享的链接中获得更多细节。但是，它应该与access_token的传输方式不一样。我错过了什么吗？ – Guru

我只提到安全漏洞，仅仅是因为它违背了规范（以及与自己的安全性相关的所有风险）。我没有看到使用id_token进行授权的任何漏洞，但我没有想到它会通过。事实上，我记得阅读（目前无法找到链接），说明团队中是否存在一个或两个令牌。它本来可以走，但他们解决了两个令牌。你在使用什么供应商OP？惊讶它不会支持定制索赔。 – sdoxsee

感谢@sdoxsee您的回应。我们的应用程序中使用的是salesforce身份。这不是一个完整的OP。 – Guru

所有授权都是本地的。这意味着具有要共享资源的服务器需要信息需要作出是否释放资源的决定。所以问题是， id_token是否具有足够的信息以及所需的保证水平来进行授权与否。这是这里唯一真正的问题。

来源

2017-08-09 22:16:20

OpenID Connect：使用id_token作为access_token可以吗？

回答

相关问题