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

Question

在我的工作中的一个应用程序中，我们正在考虑将id_token用于所有用例，包括身份验证和授权。该解决方案正在从头开始。目前没有任何资源的消费者，我们可以修改资源以使用id_token。我对openid_connect和oauth 2.0的概念有点新意。是否存在仅使用id_token具有所有访问详细信息的问题？

Answer 1

如果您的应用程序只需要对用户进行身份验证，然后让他们使用他们可以访问的所有功能访问其后端，则只需使用ID令牌并根据用户名或角色检查访问权限就更容易了。仅使用ID令牌时，您还可以接受来自不同OAuth2提供商的ID令牌。

访问令牌对于部分访问委派很有用 - 当用户将他们的一些权限委托给另一个应用程序时。例如，如果我创建的应用程序要求其用户对其GMail进行只读访问，则应用程序可以获取访问权限，而不允许其访问该用户的任何其他Google资源。

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

因此，如果您只想为其前端创建后端API并且不打算为其他应用程序打开它，那么使用ID令牌会更容易。如果您发现需要访问令牌，可以稍后再开始使用它们。

您还可以考虑根据提供的ID令牌发布您自己的令牌（JWT）以及您需要的所有身份验证和授权信息，这样您的后端就不必在每次API访问时获取用户的安全数据。

Answer 2

我建议按照设计遵循OIDC规范（即使用access_token而不是id_token进行资源服务器授权），以防止打开自己的安全漏洞。

这里讨论了如何将id_token用作access_token：https://github.com/IdentityServer/IdentityServer3/issues/2015#issuecomment-147527823

  

规范是为在客户端使用的id令牌而设计的   访问令牌以在API中使用。我相信你能想出来   一些替代协议，用于重用id令牌，但OAuth2和OIDC   只是没有这种方式发展。我确定它们是否都是从中设计的   划伤他们看起来不一样。

     

至于＆＃34;将id令牌传递给后端是否安全＆＃34; - 不确定。一世   真的没有仔细审查对它的攻击或它是如何发生的   操纵或愚弄。规范作者做了那样的事情，并且   这就是为什么我们倾向于坚持自己的领先优势，因为他们花了很多钱   我有更多的时间。

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

Answer 3

所有授权均为本地授权。这意味着具有要共享的资源的服务器需要让信息需要决定是否释放资源。所以问题是; id_token是否有足够的信息与必需的保证级别进行授权。这是唯一真正的问题。