我有一个Java Spring驱动的REST API服务器与PostgreSQL数据库连接，还有一个Java的Spring Web服务器，它使用JavaScript(现在是浏览器，但将来还有移动应用程序)将REST API的内容提供给客户端。
我已经阅读了许多关于如何保护 REST API 的文章和主题，但我还没有做出最终决定。我不想拥有基本授权，因为它没有意义，因为我需要在 JavaScript 中存储凭据，任何进入网页和开发人员控制台的人都可以轻松访问和阅读这些凭据。我不想向最终用户显示任何凭据，因此我无法将它们保留在客户端。
我已经阅读了很多关于 JWT 的信息，几乎决定实施它，但我听说它有一些缺点，从那时起就不太确定它是否是我想选择的选项。我知道还有oAuth 1.0或oAuth 2.0，但我不知道我是否想拥有这么复杂的东西。我还想将散列的用户凭据存储在我自己的数据库中，以便不依赖于任何其他凭据提供商，如社交媒体或Google。
现在，我正在我的 Web 服务器上制作另一层作为代理，希望它允许我使用 Spring Security 在此代理级别对用户进行身份验证，并具有某种或 cookie 或其他东西进行身份验证，但我不确定它是否可行，它增加了响应时间，增加了复杂性，需要我为这些端点编写控制器方法。我现在的体系结构如下：
客户端(浏览器)-> Web服务器 -> REST API 服务器 -> db
我还拒绝了所有外部连接，只允许本地主机访问 tomcat 级别的 REST API，因此我必须仅在 Web 服务器上实现安全级别，允许在 Web 服务器和 REST API 之间自由传输信息，因为它无论如何都无法访问。
Web 服务器和 REST API 与 Tomcat 实例位于同一服务器上。
我也不确定这种架构是否允许我通过 Web 服务器对移动应用程序客户端进行身份验证。
如果您能在这件事上对我提出任何建议，我将不胜感激。我在安全方面没有那么多经验，所以我有点迷茫我应该做什么。这种架构是否有意义，或者我应该直接从任何类型的客户端询问 REST API，无论是来自不同 IP 的网页还是移动应用程序，并且仅保护 Rest API？如果我想保护我的网页的某些子页面或移动应用程序的一部分，那应该是一个完全不同的层吗？
谢谢你的帮助。
您已经浏览了OAuth，JWT令牌等。如果您不想使用它们，那么您可以创建您的own token based authentication system。(说"TokenHandler")。
这个令牌处理程序将如何工作？
TokenHandler 就像一个网关服务器，即您的每个 REST API 请求都将通过此服务器应用程序进行路由。因此，您将通过authToken in header解决您对移动和Web应用程序调用的困惑。此服务器应用程序的主要职责是接受令牌，并根据维护所有令牌详细信息的数据库进行验证。此数据库将包含有关上次使用令牌进行验证时的时间戳的信息，以决定您的验证规则。
代币将如何生成？令牌可以是任何随机的 64 位字母数字字符串，并将在每次登录活动期间在数据库中生成和更新。登录 Web 服务在响应正文中返回此令牌。
什么是验证规则？这可能取决于您的业务逻辑。我更喜欢保持 15 分钟的活动会话窗口。意味着如果您访问网络服务，您将获得 15 分钟以上的活动窗口。如果您连续 15 分钟未访问任何服务，则从第 16 分钟开始，您将需要再次登录才能访问更多呼叫。这部分可以根据要求进行更改。
客户端将如何处理这个问题？客户端将存储此令牌，并在每次请求调用时传递此令牌。令牌处理程序将验证并将其请求重定向到应用程序服务器。因此，一个令牌处理程序可用于多个应用程序服务器的服务器身份验证。这可以通过应用程序端点识别器来实现。
如果您有任何问题或建议，我想进一步讨论。
为您的使用案例使用 API 网关架构模式 - http://microservices.io/patterns/apigateway.html .
API 网关(您问题中的Web 服务器)可以充当所有桌面/移动客户端的单一入口点。您可以使用会话 Cookie 或 jwt 在网关上对客户端进行身份验证。
关于网关和微服务之间以及微服务之间的身份验证，我建议相互 SSL - https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication。如果您使用的是 Spring boot，这可能会有所帮助 - http://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm
IP白名单方法的问题在于 - 它不太适合云架构，因为每次服务器重新启动时IP可能会发生变化。即使您使用专用IP，也应小心保护与SSL/TLS的通信，否则攻击者可以轻松嗅探您的流量。