如何为公共RESTful API设计非必需的身份验证

Question

如何为公共RESTful API设计非必需的身份验证

3

我有两个Node服务器，一个用于提供网站服务，另一个用于提供RESTful API服务。用户登录网站时会创建一个会话（session），这样我就可以根据用户是否已登录来向其提供正确的HTML页面。

我的API也需要对某些端点进行用户身份验证和授权。但是由于API是在不同的服务器上提供服务的（与创建登录会话的那个服务器不同），因此我无法重复使用该会话数据。此外，我希望RESTful API是公开的，并且以后希望允许外部开发人员与之交互并授权其API请求。其中一些端点需要进行授权（例如PUT请求User资源），而一些端点应该是公开的（例如GET请求User资源）。

这是我第一次设计RESTful API，我以前从未处理过这种身份验证方式。有了这些具体情况，我应该如何设计身份验证层？我对会话令牌和OAuth有一个非常简要的了解，但如果您有任何涉及这些内容的解决方案，我将感激详细解释这些内容如何结合起来创建身份验证层。同时，如果您可以提供任何有助于我学习各种技术的资源链接，我也将不胜感激！

- user1082754

2个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- jgroenen · Answer 1

我将称呼您的Web服务器为A，数据服务为B。一个简单的方案是使用私钥在B上注册A。然后，从A到B（通过https）的请求可以包括身份验证头（http://en.wikipedia.org/wiki/HTTP_header），其中包含私钥，该私钥解锁API的“私有”功能。如果没有或使用错误的私钥调用这些函数，则会返回HTTP 403 Forbidden或其他类似的错误（http://en.wikipedia.org/wiki/HTTP_403）。

- John Sheehan · Answer 2

尽可能将两者之间的身份验证方法分开，大多数对 API 的调用不会通过浏览器进行，并在代码中管理 HTTP 客户端的会话是非常繁琐的。对于通过浏览器访问的 Web 应用程序，使用基于会话的方法是正确的。

对于 API，有两种流行的添加身份验证的方式：SSL 上的 HTTP 基本认证和 OAuth 2. 我写了一篇更长的文章，介绍如何选择其中之一。虽然根据你的情况来看，简单的 HTTP 基本认证（确保使用 SSL）仅针对特定的端点进行启用可能是最好的选择。你可以让用户使用他们的正常凭据登录（浏览器会缓存这些凭据并在第一次成功认证后自动发送，以便在整个会话期间不使用 cookie），但我建议为每个网站的使用者生成一个单独的密钥/令牌对。许多不使用 OAuth 的受欢迎的公共 API 都采用了这种方法（例如 Twilio）。