我正在实现一个连接到OAuth2服务器的应用程序，它得到了一个Json Web令牌（JWT）。 我正在传递令牌，我想独立地验证该令牌是否来自发行源。
我可以用发行源的公钥来做这件事，没有问题。 我现在有它。 一切都能正常工作。
但如果OAuth服务器更改了签名密钥呢？ 验证应用程序如何获得新的密钥？ 是否有一个 "最佳实践 "惯例来共享来自OAuth2服务器的公钥？ 我们是否只需要从Auth服务器上的一个端点暴露它？
没有一个解决方案是标准化的OAuth 2.0协议套件的一部分（今天）。
它被认为是一个单一领域的问题，将以各种方式解决，而这些方式被认为不在核心OAuth规范的范围内（就像资源服务器和授权服务器之间的API是一样的），就像今天任何基于PKI的一般机制工作一样。
但OpenID Connect是建立在OAuth 2.0之上的跨域SSO协议，它还定义了一个更标准化的选项，即以JWKs URI的形式处理密钥分发，作为Discover的一部分，见于 jwks_uri 进入在。
REQUIRED。OP的JSON网络密钥集[JWK]文件的URL。这包含RP用来验证OP签名的签名密钥。JWK集还可以包含服务器的加密密钥，RP用于加密向服务器发出的请求。当签名和加密密钥都可用时，引用的JWK集中的所有密钥都需要一个使用（密钥使用）参数值，以指示每个密钥的预期用途。虽然有些算法允许同一密钥同时用于签名和加密，但不推荐这样做，因为它的安全性较低。JWK x5c 参数可以用来提供所提供的密钥的 X.509 表示。当使用时，裸密钥值必须仍然存在，并且必须与证书中的密钥值相匹配。
这将通过HTTPs保护通道暴露密钥材料，有效地利用SSL CA来发布和滚动JWT签名密钥材料。
在某些时候 jwks_uri 定义可能也是标准化OAuth 2.0协议扩展的一部分，但现在你必须依靠客户端和授权服务器之间的自定义协议来实现。不过这可能并不难自己实现。
如果你的授权服务器恰好也是OpenID Connect提供商，并且使用相同的密钥材料来签署ID令牌以及JWT访问令牌，你可能会很幸运。
4222019年更新：授权服务器元数据文档现在也标准化了它自己的OAuth 2.0扩展OAuth 2.0授权服务器元数据。RFC8414