在SSO场景中，客户端系统如何“信任”OIDC身份令牌(或oAuth2授权访问令牌)？

Question

首先，让我们澄清一下，我们知道OIDC和oAuth2是不同的协议，尽管OIDC基于oAuth2定义的流和机制，它们还使用不同的令牌、用于OIDC的JWT标识令牌和oAuth2的资源访问令牌(也可能是JWT格式化的，但不是必需的)；第一个处理联邦身份验证问题，第二个处理联邦资源访问授权问题)。

尽管如此，对于这个特定的问题，我们所拥有的令牌类型多少并不相关，因为在这里，我们对客户端系统信任令牌合法性的机制感兴趣(请理解客户端系统的oAuth2流定义所定义的客户端系统，以及能够接受这些相同的数字签名令牌的任何额外系统)。

为了简化论证，让我们假设我们遵循的是一个auth代码授予流。在这个流程中，最终用户已经被重定向到Id/auth服务器，成功地提供了他的凭据，并被重定向回原来的“颁发者客户端”；我们可以确保这个“颁发者客户端”可以信任这个令牌，因为它是通过提供访问代码的反向信道http请求获得的，并且提供了其他任何人都不知道的客户端秘密，因此对于这个“颁发者-客户端”来说，信任这个令牌是微不足道的。让我们把这称为“微不足道的情况”。

现在，让我们假设有更多的客户端系统能够接受以前生成的令牌-as，只要该令牌当然是有效的(这确实是SSO的一种形式，因为这些系统基本上是“绕过”了它们的最终用户登录，因为它们信任以前由另一个客户端生成的令牌)。我的问题是，那些其他客户机(最初没有像前面描述的那样发布令牌)如何信任这个令牌的合法性？

解决上述段落中的问题的一种方法是，当客户端显示一个令牌时，“询问”id/auth提供程序是否确实生成了令牌；但是在不同的文档&博客中，我看到客户端系统通常接受令牌而不与Id/auth提供程序交互。如果令牌本身就足以建立信任，这是如何发生的呢？有人提到，数字签名确保没有人更改令牌，但是这些系统如何知道令牌不是由其他-potentially恶意标识/auth服务器生成的？假设我们有第二个身份/授权服务器，它在结构上与第一个服务器的令牌相同；在这种情况下，客户如何知道令牌来自auth服务器1而不是auth服务器2？如果客户端能够100%确定一个令牌不仅没有被更改，而且是由客户所知道和信任的权威机构生成的，那么这些令牌似乎需要将特定于生成令牌的Id/auth服务器的某些信息作为其数字签名的一部分，并且不能被任何仿真器复制(客户端知道如何解码)。

这就是我的问题的要点，“非发行者-客户”(当呈现一个令牌时)，在不与Id/auth提供程序交谈的情况下，如何知道接收到的令牌不仅没有被更改(这是签名)，而且还知道它们来自哪个Id/auth提供者，以及如何防止“假Id/auth提供者”能够生成几乎相同的或者完美的令牌。

谢谢你的反馈，很抱歉我的英语能力有限，这是一个复杂的话题，问题可能不是以最好的方式表达出来的。

Answer 1

接收令牌的API通常会查询令牌提供者/.著名/openid配置端点来下载公开签名密钥。

然后，当API接收到访问令牌时，它可以使用API信任的提供者的公钥，并验证访问令牌是真实的，并且没有被修改。

在令牌内部通常也有一个受众声明，它指定令牌的目标是谁，以及描述谁发布令牌的声明。

因此，对于接收访问令牌的资源来说，有许多方法来验证它是否值得信任。