通过REST API进行身份验证并保护API本身

Question

我使用Jersey 2.x为我的应用程序实现了REST API。我采用REST方法是因为我计划稍后添加移动应用程序。现在它只是一个网络应用程序。我正处于考虑安全问题的地步。我需要处理两件事。

1. 对用户进行身份验证和授权：现在，我正在使用基于HTTP的HTTP Basic身份验证。但有没有更好的方法，而不是让用户通过网络发送用户名和密码。我理解它是通过HTTPS但我正在探索。想到了OAuth 1.0a。我在正确的轨道上吗？
2. 保护API本身：我不希望除了我的网络应用程序之外的任何其他客户端都在白名单中。我稍后会将我的移动应用添加到此白名单中。我想象某种秘密钥匙来识别这个客户？

我认为上面的＃1和＃2都可以使用OAuth 1.0a完成，但就安全和授权而言，它们是两种不同的实现方式。它们可以共存吗？您能否向我提供有关如何入门的指示以及现实世界中的一些示例？

有很多信息，但安全性不是我的强项，我试图通过在我自己的应用程序中自己编码来理解。

Answer 1

我的第一个建议是让你研究OAuth 2.0，我不打算讨论它是否比OAuth 1.0a更好或更差但它似乎有更广泛的采用，因此对你来说会更容易在线查找资源; OAuth2还在HTTPS的肩膀上存放了大量的安全功能，你似乎已经在使用它了。

关于将HTTP基本认证与OAuth2进行比较，我会检查this answer的一些优缺点，但就大局而言：

  

使用基本身份验证时，每个请求中都会包含完整凭据，而使用OAuth2则是每个请求中包含的访问令牌。

关于使用密钥识别每个客户端应用程序，OAuth2确实支持这一点，但是，如果您计划拥有（本机）移动应用程序，那么您面临着巨大的挑战，因为这些应用程序无法真正保密（攻击者可以对您的应用程序进行逆向工程并找到秘密）。

总之，对于传统的Web应用程序，很容易确保您的API仅允许访问确实使用白名单应用程序的授权用户。如果您要将API打开到原生移动应用程序，您将很难证明该呼叫来自您的某个授权应用程序。

有关常见OAuth2方案的示例，我会检查Auth0 Architecture Scenarios。