OAuth 2的access_token与OpenId Connect的id_token有何区别？

Question

尽管我之前已经使用过OAuth 2，但我对Open ID Connect还是新手。

阅读教程和文档时，我遇到了access_token和id_token。其中access_token是根据OAuth 2生成的随机唯一字符串，而id_token是JSON Web Token，其中包含用户ID、算法、发行者和各种其他信息，可用于验证它。我也看到了API提供者同时提供access_token和id_token，据我所知这是为了向后兼容。

我的问题是是否可以同时使用access_token和id_token来访问受保护的资源？或者id_token只用于验证目的，access_token用于访问受保护的资源？

- ajaybc

---

请注意，access_token通常是一个随机数，而id_token包含有关用户的一些私人信息：例如姓名、电子邮件和可能还有其他信息。因此，在系统中广泛使用id_token并不是一个好主意，因为它可能会泄漏，例如被打印到日志中或显示在错误页面上等。 - Sergey Ponomarev

Answer 1

最初，OAuth和OpenId是为不同的目的而设计的：OpenId用于身份验证，OAuth用于授权。OpenId Connect是两者的统一，并且可以同时用于身份验证和授权，但不改变它们的原始功能。牢记这一点，你应该能够自己找到答案。 ;-)

id_token用于标识已经通过身份验证的用户，例如用于单点登录。access_token必须用于证明对受保护资源的访问权限，例如用于OpenId Connect中的userinfo端点。

- Zólyomi István

---

我对OpenID Connect和OAuth2实现有些困惑。我有一个前端（HTML，AngularJS）和后端Web服务。现在我想在登录期间实现基于令牌的机制，因此用户将发送clientid、emailid、password，并在后端验证客户端ID和其他凭据后，我将向用户发放一个令牌，通过该令牌用户将维护用户会话。那么OpenID Connect在哪里发挥作用，它对我有何用处？您能否为我提供一些见解，因为我真的很困惑。 - Learning-Overthinker-Confused

据我所知，您不需要授权，只需要身份验证。如果是这样，那么您应该简单地使用OpenId或SSO解决方案，但您根本不需要OAuth或OpenId Connect。 - Zólyomi István

@ZólyomiIstván，对于SPA而言，它似乎使用'id_token'代替'access_token'。在这种特殊情况下，'id_token'是否真的取代了'access_token'呢？原因之一是SPA无法与OAuth Token Endpoint通信，因为存在CORS策略。 - Ashokan Sivapragasam

Answer 2

另一个角度的解答：

id_token

• id_token是JWT——请注意！
• 它包含有关用户/资源所有者身份的声明
• 拥有有效的id_token意味着用户已通过身份验证

access_token

• access_token是持票据令牌
• 持票据令牌表示持有人可以访问资源而无需进一步的身份验证
• access_token可以是JWT（见附录第1点）或opque不透明的令牌

如需了解更多信息，请参阅：OIDC和OAuth中的令牌类型

- human

Answer 3

access_token是在Auth0中调用特定API（例如/userinfo）或您在Auth0中定义的API时非常有用的。

id_token是JWT并代表已登录用户。它经常被您的应用程序使用。

是否可以同时使用access_token和id_token来访问受保护的资源？

不完全可以，首先，您需要使用id_token登录，
其次，您将获得一个accessToken，
最后，使用accessToken访问数据。

- Mike Yang

---

对于SPA来说，似乎它在'access_token'的位置使用了'id_token'。是否真的如此，在这种特殊情况下'id_token'接管了控制权呢？一个原因是SPA不能访问OAuth Token Endpoint，因为CORS策略的缘故。 - Ashokan Sivapragasam

Answer 4

这里有一篇文章，介绍了为什么引入id_token以及它最初的目的：为什么我们需要在OpenID Connect和Facebook Connect中使用id_token。简单来说，他们试图标准化Facebook使用的混合流程。

我们考虑使用id_token作为access_token。 我们拒绝了这个选项，因为：

• 许多提供商已经存在其端点的OAuth token格式，难以更改。
• 我们不希望长期访问令牌作为cookie存储在浏览器中。
• 明显存在两个令牌的不同接收者，过载两个令牌的语义会降低长期的灵活性并增加复杂性。

- Sergey Ponomarev