应用服务器是否使用jwt id令牌进行用户识别，还是jwt id令牌旨在发送到资源服务器以能够识别用户？
Oauth可以用于身份验证、授权和委托。Oauth流最终导致应用服务器接收访问令牌（和刷新令牌）和jwt ID令牌（openidconnect）。
应用服务器可以使用访问令牌将其传递给资源服务器，以代表用户访问资源(委托)。
应用服务器是否将Jwt id令牌传递给资源服务器以通知资源服务器当前用户是谁？还是应用服务器使用jwt id令牌对用户进行身份验证以允许应用服务器知道当前用户是谁？
共有2个答案
ID令牌仅证明用户经过身份验证并提供用户的配置文件数据。它不包含任何可以证明用户确实确认资源服务器被允许对其资源执行某些操作的信息（即没有OAuth2作用域）。
因此，仅将 ID 令牌传递给资源服务器无法帮助它做出授权决策。即使资源服务器可能会使用 ID 令牌来找出用户是什么，然后找出他有什么权限，但它仍然不能证明用户真的确认委托应用服务器对其资源执行某些操作。（即我有权做某事并不意味着我同意你代表我做。
因此，请始终将访问令牌传递给资源服务器以做出授权决策。
你也可以参考这篇博客文章，它也可以回答你的问题。
根据规范，应用服务器不应将id_token传递给其他任何内容。
提供给资源服务器的数据应根据传递给授权服务器的作用域并包含在access_token中确定。
您可以将access_token发送到资源服务器，然后资源服务器调用userInfoendpoint。
请记住，这与最终用户授权谁接收什么数据有关。
在https://github . com/identity server/identity server 3/issues/2015上有关于这些主题的相当长的讨论
-
下面是官方指南中的GCM Android集成示例。 特别是，我对上述链接类中的以下行感到困惑： 现在，每当我的主要活动启动时，我都会调用intent服务，我相信instanceID负责启动令牌刷新。 我是否应该在每次从我的主要活动启动此GCM注册意图时检查Shared Prefs值。但是，在这种情况下刷新将失败，因为在初始令牌获取之后，条件将始终为true。 我应该放弃共享prefs逻辑吗？这样每
-
我有两个云运行服务:和。前端是用vue.js/nuxt.js编写的，因此使用的是节点后端。后端是用Kotlin编写的，带有Spring Boot。 为了在前端和后端之间进行经过身份验证的内部通信，我需要使用一个令牌thttps：//cloud.google.com/run/docs/authenticating/service-to-service#JavaHat是从google Metaserv
-
我们有一个Springboot应用程序（比如microservice-a），我们需要添加一个带有OAuth2令牌的HTTP授权头来访问另一个microservice（比如microservice-B）。另外，据说我们可以通过向同一个microservice-B发送带有Grant\u类型、作用域和基本身份验证用户名和密码的HTTP POST请求来检索这个OAuth2令牌。 现在我的疑问是，我们是否有
-
我正在尝试允许第三方应用程序（Google Home）访问AWS Cognito用户池中的信息。 整个流程如下（假设我理解正确）： 用户试图将他们的设备（都在各种AWS服务中管理）链接到Google Home。 然后用户被重定向到我们的oauth2页面，在那里他们登录到cognito用户池中的帐户 他们成功登录并获得oauth令牌 Google Home应用程序可以使用该令牌向我们的后端发送请求，
-
我是GCM新手，不清楚客户端和应用服务器之间的注册过程。由于GCM上游消息是可用的，当客户端向GCM注册时，GCM是否可以将注册数据发送到app server，这样android客户端就不必像以前那样将注册令牌/id发送到app server？ 我在某处看到了一个消息推送图，显示应用服务器和客户端之间没有连接。所有的通信都可以通过GCM。 谢谢！