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

Question

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

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

我想上面的＃1和＃2都可以用OAuth 1.0a来完成，但它们是两种不同的实现方式，它们是受保护和授权的。他们能共存吗？你能否向我提供关于如何开始和现实世界中的一些例子的任何指示？

这里有很多信息，但安全并不是我的强项，我试图通过自己编写自己的应用程序来理解它。

Answer 1

我的第一个建议是让你看看OAuth 2.0，我不打算讨论它是比OAuth 1.0a更好还是更差，但它似乎有更广泛的采用，因此它会更容易你在网上找资源; OAuth2还将很多安全功能存放在HTTPS的肩膀上，您似乎已经在使用它。

关于HTTP基本验证比较的OAuth2我会检查this answer一些优点和缺点，但在大局方面：使用基本身份验证

全凭据总是包含在每个请求，而使用OAuth2它是每个请求中包含的访问令牌。

关于确定了密钥的每个客户端应用程序，这在OAuth2用户确实是支持，但是，如果您计划（本地）移动应用程序，你有一个很大的挑战，因为未来这些应用程序不能真正保守秘密（攻击者可以对您的应用程序进行逆向工程并找到秘密）。

总之，对于传统的网络应用程序，很容易确保您的API只允许访问授权用户，该用户确实正在使用您的白名单应用程序。如果你想打开你的API到原生移动应用程序，你将很难证明这个电话真的来自你的授权应用程序之一。

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