我已经准备了很多stackoverflow的答案，看了很多youtube视频，读了很多文章，但我仍然不能完全理解为什么我们需要两个令牌。以下是我的假设，请告诉我哪里错了:
访问令牌:
-
某个oauth流的结果，其中一个应用程序代表我请求访问资源。
-
包含关于已授予访问权限的信息
-
可以是任何字符串格式(不一定是JWT)，唯一重要的是预期的接收者能够理解它。
-
可能包含授予访问权限的人(Me!)的ID信息
-
必须保密!
ID标记:
-
oidc流结果(oauth流顶部的扩展)
-
包含认证的用户(Me!)的信息，例如他们的用户名。
-
的目的无非是一个标准化的方式来分发有关用户的信息。使用Id令牌
实际上没有执行任何操作 -
可以无危险地泄漏。
访问令牌"flow";
用户X希望服务A代表它访问服务B
用户X被定向到服务B并验证
服务B向服务A发送访问令牌
业务A现在可以根据令牌中包含的访问权限代表用户X访问业务B。
Id token "flow";
用户X通过"登录到业务b"注册业务A
用户X被引导到业务B并进行认证。
服务B发送Id令牌给服务a
服务A现在可以显示个性化的欢迎信息"Hello User X">
这是错的还是我错过了什么?
我认为用户X可能会对服务B进行身份验证，并向服务A授予服务B的某些UserInformationAPI的访问权限(访问令牌)，然后服务A可以使用该令牌查询服务B以读取用户信息，这在本质上与直接将标准化Id令牌传递给服务A的结果相同，我认为这是错误的吗?
ID令牌和访问令牌将带来相同的结果，如果您限制讨论仅获取用户信息。在ID令牌的情况下，您可以在ID令牌的有效负载部分中找到用户信息。在访问令牌的情况下，您可以通过在userinfo端点呈现访问令牌来获取用户信息。
但是，如果您想做除获取用户信息之外的其他事情，换句话说，如果您想访问除userinfo端点之外的其他Web api，则需要访问令牌。
ID令牌和访问令牌之间的一个简单区别是ID令牌由客户端解释，而访问令牌由资源服务器解释.
值得一读">Identity Federation by OpenID Connect"。文章中的第14步如下:
步骤14
ID令牌的有效负载部分包含有关用户的信息。如果信息不够， userinfo端点(OpenID Connect Core 1.0 Section 5.3 userinfo endpoint)可以被利用。注意，userinfo端点需要一个至少覆盖
openid范围的访问令牌。
ID令牌只是身份验证事件的证明。如果需要，web或移动客户端可以看到用户身份验证的方式和时间。但是，在大多数用例中，应用程序代码会忽略ID令牌。不应该从客户端发送ID令牌。
当web应用使用自己的cookie层时，它可能会在接收令牌并验证ID令牌后发起会话。
访问令牌是重要的。这些是用来保护您的数据。在OAuth中，一旦用户身份验证完成，客户机(或问题中的用户X)就会从授权服务器获得一个授权服务器。令牌没有从服务b返回
访问令牌可以在相关服务(同一组织内)之间转发。访问令牌有效负载中的范围、声明和受众是可用于实施访问控制的机制。如何设计这个取决于你。