在微服务架构的每个服务中验证访问令牌 (JWT)答案

【问题标题】：Verifying Access Token (JWT) in Each Service of a Microservices Architecture在微服务架构的每个服务中验证访问令牌 (JWT)
【发布时间】：2018-02-24 22:44:21
【问题描述】：

我有一个使用微服务架构实现的应用程序。有一个使用 jwt 标准的身份验证服务（A），应用程序中还有其他服务，如 S1、S2、S3 等。现在例如 S1 收到一个请求，它应该验证令牌以查看用户是否被授权。验证可以通过：

将令牌从 S1 发送到 A，然后 A 验证令牌并将结果发送到 S1（这是一种开销）
在 S1 中验证令牌（这是每个服务中的重复操作，还需要每个服务中的密钥或公钥/私钥，用于签名/验证）

我不是在问这些方法究竟是如何工作的。问题是，其中哪一个更好？或者在这种情况下最佳做法是什么？

【问题讨论】：

深思熟虑。身份验证与授权不同。（这里的上下文是 OAuth 和 OpenID）cakebaker.42dh.com/2008/04/01/… 您可以在设计中考虑这一点，因为您在上面的描述中“双重使用”“A”。

标签： rest authentication architecture cloud microservices

【解决方案1】：

我建议将您的身份验证服务打包在另一个微服务中并与之通信以进行身份验证。（基本上是您的第一个选项。）

在微服务生态系统中，您可能有 10 多个（如果不是数百个）应用程序运行（理想情况下）彼此完全独立。使用第二个选项，您每次启动新服务时都会添加样板。但也许更重要的是，您已将所有微服务耦合到当前的身份验证方案。最好将所有身份验证放在一个界面后面，并将所有身份验证逻辑隐藏在一个单独的位置。

【讨论】：

是的，不要重复自己..应该保持有效。

【解决方案2】：

我认为您需要同时考虑这两种解决方案并考虑权衡取舍。

拥有单一的服务处理授权：

单点故障。如果有人犯了错误，那么你的整个生态系统就会崩溃。
增加对众所周知的问题的封装。
减少所有依赖服务的工作。

对每个服务实施授权：

赋予每个服务更多的独立性（这是“微服务”的本质）
让您可以灵活地选择如何保护您的每项服务。可能会根据每个人的意图而有所不同。

最后，您需要找到自己的需求，并根据什么能给您带来更多好处做出决定。我只是列出了一些优点和缺点，但我认为这个想法是在这个主题上投入时间，然后根据你认为最适合你的团队的方式做出决定。

【讨论】：