我一直在阅读OAuth 2.0授权代码流，以保护微服务架构中的API，但我不明白Auth服务器发布的访问令牌应该如何保护另一台服务器中托管的API。
API中是否也保留了相同的访问令牌？当客户端尝试使用Auth Server颁发的访问令牌访问该令牌时，API会检查是否包含该令牌？如果是，这是否意味着访问令牌在身份验证过程中同时发送到客户端和受保护的API？
我希望能很好地解释我的问题。提前谢谢。
Anunay很好地模拟了JWT如何作为可移植、可信任的标识符在高层工作，但由于OAuth支持的不仅仅是JWT身份验证，因此可能需要共享更多细节。
令牌内省
在您的问题中，您正确地假设令牌需要某种方式来获得信任，其中一种方式是将令牌存储在专用数据库中，并在令牌出现时进行查找以确定其有效性。您完全可以使用这样的方法来检测有效的OAuth服务器，方法是使用您想要的任何形式发布令牌，并编写一个执行查找的内省端点。OAuth规范是有意抽象的，因此令牌内省的功能行为可以采取多种形式。
这种抽象级别的原因之一是，虽然存储用于直接查找的令牌可能很容易，但这意味着您必须将这些令牌的副本以某种形式存储在专用数据库中进行比较。这种存储反过来会让你成为内部和外部不良行为者的蜜罐，他们会试图冒充你的用户。正是出于这个原因，许多OAuth实现更喜欢使用公钥/私钥加密而不是直接查找来发布和验证令牌。这个过程非常像Anunay在评论中描述的过程，因为它发布用私钥签名并用公钥验证的令牌。有了这个过程，您不再需要将每个人的令牌都保存在私有数据库中，而只需要保护分别用于签名和验证令牌的私钥和公钥。
JSON Web令牌(JWT)和减少内省调用的数量
Anunay的回应特别提到了一种使用公钥/私钥加密生成并颁发给用户的通用令牌结构，即JSON Web令牌。这些令牌的结构使得它们以后端API可直接读取的原始格式包含后端服务可能需要的用户信息，如用户ID、电子邮件地址，有时甚至更多。然而，除了这些原始信息之外，JWT还包括数据的副本，但该副本是私钥加密的。为了信任JWT令牌，您所要做的就是使用公钥，并通过将公钥应用于原始有效载荷来确保私钥编码的有效载荷是可验证的。由于公钥很少更改，许多后端服务缓存用于验证的密钥，并选择不在发布服务器上进行令牌内省，因为它们已经可以验证有效负载。这就是如何优化通过OAuth保护的后端服务的吞吐量。
由于公钥只能用于验证有效载荷，而不能生成有效载荷，因此这些公钥通常由发布令牌的服务器进行广播，允许任何人"信任"其发布的令牌(如果他们愿意的话)。要了解有关此过程的更多信息，我建议您研究OpenIDConnect。
访问令牌可以理解为政府根据身份证明颁发给公民的护照。当你把它带到另一个国家时，他们会看到这份文件并信任它，因为他们信任这个国家，信任你，因为你是这份文件的持有人，里面有你的详细信息。他们相信护照不会被篡改，并允许你进入
现在，对于访问令牌，简单地说，授权服务器验证用户。一旦验证，它就会向用户发出JWT令牌(访问令牌)。此令牌是用私钥签名的。它有您的详细信息，并与签名一起编码。现在，您可以将此令牌带给任何获得公钥并信任授权服务器的第三方。现在，当您与第三方共享访问令牌时，它会使用公钥来验证令牌并检查是否过期。如果有效，它允许您进入。因此，API实际上不需要与身份验证服务器对话，也不需要保留有关令牌的任何详细信息。它所需要的只是一个用于解码令牌的公钥。
现在有两件重要的事情。一个是，如果你释放了你的访问令牌，或者某个不想获得你的令牌的人得到了它，他可以随心所欲，而身份验证服务器将无法做太多事情。然而，正如您所看到的，这种方法减少了系统的聊天性，特别是微服务。
因此，为了解决这个问题，我们限制了访问令牌的到期时间。就像护照一样，它也会过期。保存时间越短，用户就必须使用auth服务器刷新令牌。每次他这样做时，auth-server都会得到一个更改来验证creds和其他详细信息。如果它们不匹配，则不会刷新访问令牌。