资源服务器应如何验证授权服务器颁发的 oauth 不记名令牌？
How resource server should validate oauth bearer token that issued by Authorization Server?
假设我有一个授权服务器 (AS)，它应该生成 access_token，并且我有另一个资源服务器 (RS)，它为我的受保护资源提供服务。
我想知道 RS 应该如何验证 AS 生成的 access_token？
我的困惑是，AS 应该有其签名的秘密方式 access_token，这不意味着共享或被任何其他人知道，在这种情况下，RS 不应该知道 AS 是如何生成的这个access_token.
在这种情况下，RS 应该如何验证收到的令牌并确保令牌来自已识别的 AS？相反，AS 不应该负责验证在 RS 上收到的令牌吗？但如果是这样的话，它不会面临任何性能瓶颈吗，因为每次 API 对 RS 的调用都需要额外跳到 AS 来验证令牌？
通常情况下，AS 发行的令牌是使用私钥签名的。 AS 还发布了 public 密钥供任何人下载。例如 Google 发布其 public 签名密钥 here.
稍后，当 RS 收到 access-token 时，它会从 AS 下载 public 密钥并验证令牌的签名。如果匹配则接受。除了验证签名外，它还会检查令牌内的其他声明，例如 aud-claim（观众）他的令牌是否真的供 RS 使用。
或者，RS 可以使用共享密钥来验证令牌。在这种情况下，RS 是一个可信的（机密客户端），我们知道它可以保守秘密，并且可以安全地与我们信任的服务共享秘密。
正如你所说的艾萨克，有些人（包括我自己）更喜欢从 APIs 外部化令牌验证并要求授权服务器完成工作。我认为这是自以下以来最干净的选择：
- 它从您的所有 API
外部化安全代码
- 可以在不影响 APIs
的情况下更改令牌签名密钥或算法
这可以通过 introspection 实现，这通常还涉及缓存结果（声明）。这就是很多 API 网关解决方案的工作方式，但您也可以很容易地自己编写代码。
我的一些相关资源：
Tore 描述的技术也完全有效，如果授权服务器不支持内省，则这是一项要求。
假设我有一个授权服务器 (AS)，它应该生成 access_token，并且我有另一个资源服务器 (RS)，它为我的受保护资源提供服务。
我想知道 RS 应该如何验证 AS 生成的 access_token？
我的困惑是，AS 应该有其签名的秘密方式 access_token，这不意味着共享或被任何其他人知道，在这种情况下，RS 不应该知道 AS 是如何生成的这个access_token.
在这种情况下，RS 应该如何验证收到的令牌并确保令牌来自已识别的 AS？相反，AS 不应该负责验证在 RS 上收到的令牌吗？但如果是这样的话，它不会面临任何性能瓶颈吗，因为每次 API 对 RS 的调用都需要额外跳到 AS 来验证令牌？
通常情况下，AS 发行的令牌是使用私钥签名的。 AS 还发布了 public 密钥供任何人下载。例如 Google 发布其 public 签名密钥 here.
稍后，当 RS 收到 access-token 时，它会从 AS 下载 public 密钥并验证令牌的签名。如果匹配则接受。除了验证签名外，它还会检查令牌内的其他声明，例如 aud-claim（观众）他的令牌是否真的供 RS 使用。
或者，RS 可以使用共享密钥来验证令牌。在这种情况下，RS 是一个可信的（机密客户端），我们知道它可以保守秘密，并且可以安全地与我们信任的服务共享秘密。
正如你所说的艾萨克，有些人（包括我自己）更喜欢从 APIs 外部化令牌验证并要求授权服务器完成工作。我认为这是自以下以来最干净的选择：
- 它从您的所有 API 外部化安全代码
- 可以在不影响 APIs 的情况下更改令牌签名密钥或算法
这可以通过 introspection 实现，这通常还涉及缓存结果（声明）。这就是很多 API 网关解决方案的工作方式，但您也可以很容易地自己编写代码。
我的一些相关资源：
Tore 描述的技术也完全有效，如果授权服务器不支持内省，则这是一项要求。