ID令牌用于OAuth客户端读取，访问令牌用于资源服务器读取。
因此，如果您的服务器应用程序是前端的后端（如浏览器中的JavaScript、移动的应用程序），OAuth2客户端角色属于该前端应用程序，因此ID令牌应保留在那里，前端不应将其发送到后端（资源服务器角色）。前端应将访问令牌发送到后端。然后，后端可以将访问令牌用于各种目的：

• 如果是JWT形式，直接读取并验证
• 如果令牌只是一个随机字符串，则使用它从OAuth2内省端点获取用户信息和范围
• 使用获取的信息允许/拒绝对请求资源的访问（基于作用域、角色、用户或仅基于令牌的有效性）

访问令牌对于部分访问委派也很有用-当用户将他们的一些权限（范围）委派给具有OAuth客户端角色的应用程序时。例如，如果我创建一个应用程序，要求其用户对其GMail进行只读访问，则该应用程序可以获得访问权限，而不允许其访问用户的任何其他Google资源。
访问令牌可以失效，ID令牌不能。因此，在可疑活动的情况下，OAuth服务器可能会使令牌失效，以防止其滥用。资源服务器应在请求自检端点时发现这一点。
访问令牌的生存期有限，OAuth客户端必须使用刷新令牌请求新的访问令牌。
如果您的应用程序只是一个生成HTML表示的简单服务器，并且它具有OAuth2客户端的角色（它初始化auth请求），则服务器可以使用接收到的ID令牌来读取有关已验证用户的信息。基于此，您可以创建服务器端会话来保存用户信息，并使用浏览器cookie进行进一步验证（不使用OpenID Connect协议）。

我建议按照设计遵循OIDC规范（即，使用access_token而不是id_token进行资源服务器授权），以防止出现安全漏洞。
There's a good discussion here about using id_token as an access_token: https://github.com/IdentityServer/IdentityServer3/issues/2015#issuecomment-147527823
这个规范是为客户端使用的id令牌和API使用的访问令牌设计的。我相信你可以想出一些替代协议来重用id令牌，但是OAuth2和OIDC并没有这样发展。我相信如果它们都是从头开始设计的，它们看起来会不同。
至于"将id令牌传递到后端安全吗"--不确定。我真的没有仔细研究过针对它的攻击，或者它是如何被操纵或愚弄的。规范作者做了这类事情，这就是为什么我们倾向于坚持他们的领导，因为他们在这上面花了比我更多的时间。
问题是，为什么要使用id_token而不是access_token？获取一个真正的access_token很容易，为什么要违背规范呢？

• • 更新日期：**

如果您确实允许在资源服务器上使用id_token（请注意），您需要将允许调用您的API的每个客户端"受众"列入白名单，除非您希望通过您的提供程序验证的任何应用程序调用您的API!再次，我建议您遵循规范，否则您将在缺乏可靠指导的情况下创建安全漏洞。

所有的授权都是本地的，这意味着拥有共享资源的服务器需要有信息来决定是否释放资源，所以问题是; id_token是否具有足够的信息，并具有所需的保证级别以进行授权。这是这里唯一真实的的问题。