如何保护 RESTful Web 服务？

还有另一种非常安全的方法。这是客户端证书。当您在 https 上联系服务器时，知道服务器如何呈现 SSL 证书吗？好吧，服务器可以向客户端请求证书，这样他们就知道客户端就是他们所说的那个人。客户生成证书并通过安全通道将其提供给您（例如使用 USB 密钥进入您的办公室 - 最好是非木马 USB 密钥）。

您将证书客户端证书的公钥（以及他们的签名者证书，如有必要）加载到您的 Web 服务器中，并且 Web 服务器不会接受来自任何人的连接，除了拥有证书相应私钥的人它知道。它在 HTTPS 层上运行，因此您甚至可以完全跳过 OAuth 之类的应用程序级身份验证（取决于您的要求）。您可以抽象出一层并创建本地证书颁发机构并签署来自客户端的证书请求，从而允许您跳过“让他们进入办公室”和“将证书加载到服务器上”步骤。

脖子疼？绝对地。对一切都有好处吗？没有。非常安全？是的。

然而，它确实依赖于客户保持他们的证书安全（他们不能在线发布他们的私钥），并且通常在您向客户出售服务而不是让任何人注册和连接时使用它。

无论如何，它可能不是您正在寻找的解决方案（它可能不是诚实的），但它是另一种选择。

HTTP Basic + HTTPS 是一种常用方法。

如果在 OAuth 版本之间进行选择，请使用 OAuth 2.0。

OAuth 不记名令牌只能与安全传输一起使用。

OAuth 不记名令牌仅与加密对话的传输一样安全或不安全。 HTTPS 负责防止重放攻击，因此不记名令牌也没有必要防止重放。

确实，如果有人拦截了您的不记名令牌，他们可以在调用 API 时冒充您，但有很多方法可以降低这种风险。如果你给你的令牌一个很长的有效期，并希望你的客户在本地存储令牌，那么你有更大的令牌被拦截和滥用的风险，而不是你给你的令牌一个短暂的有效期，要求客户在每个会话中获取新的令牌，并建议客户不要保留令牌。

如果您需要保护通过多个参与者的有效负载，那么您需要的不仅仅是 HTTPS/SSL，因为 HTTPS/SSL 只加密图表的一个链接。这不是 OAuth 的错误。

不记名令牌易于客户端获取，易于客户端用于 API 调用，并且广泛用于（通过 HTTPS）保护来自 Google、Facebook 和许多其他服务的面向公众的 API。