我有两个节点服务器。一种服务于网站，另一种服务于为网站背后的数据提供支持的 RESTful API。
当用户登录网站时，会创建一个会话。然后，这允许我根据用户是否登录为用户提供正确的 HTML。
我的 API 还需要为某些端点识别和授权用户。但是，由于 API 是在不同的服务器上提供的（与创建登录会话的服务器不同），我无法重新使用该会话数据。此外，我希望 RESTful API 是公开的，并且以这种方式重用会话数据可能会阻止这种情况。公开我的意思是从长远来看，我希望允许外部开发人员与他们的 API 请求进行交互和授权。一些端点需要被授权（例如PUT在User资源上），而一些端点应该是免费供所有人查看的（公共的；例如GET在User资源上）。
这是我的第一个 RESTful API，我以前从未以这种方式处理过身份验证。考虑到这些细节，我应该如何设计我的身份验证层？
我对会话令牌和 OAuth 有一个非常简要的了解，但是如果您有一个涉及其中任何一个的解决方案，我希望能详细解释这些东西如何结合在一起以创建身份验证层。任何帮助我学习各种技术的资源链接也将不胜感激！
我将调用您的网络服务器 A 和您的数据服务 B。一个简单的方案是使用私钥在 B 上注册 A。然后，从 A 到 B（通过 https）的请求可以包含带有私钥的 Authentication 标头（ http://en.wikipedia.org/wiki/HTTP_header ），从而解锁 API 的“私有”功能。如果在没有或使用虚假私钥的情况下调用，这些函数将返回 HTTP 403 Forbidden 或其他内容（http://en.wikipedia.org/wiki/HTTP_403）。
您需要尽可能地保持两者之间的身份验证方法分开。大多数对 API 的调用不会通过浏览器，并且在代码中管理 HTTP 客户端中的会话是一个巨大的痛苦。对于通过浏览器的 Web 应用程序，基于会话的方法是正确的方法。
对于 API，有两种流行的添加身份验证方法：基于 SSL 的 HTTP 基本身份验证和 OAuth 2。我写了一篇较长的文章来介绍如何选择一种。尽管对于您的情况，这听起来像是为特定端点选择性启用的简单 HTTP 基本身份验证（确保使用 SSL）可能是要走的路。您可以让您的用户使用他们的正常凭据登录（浏览器将对其进行一些缓存并在会话的剩余部分的第一次成功验证后自动发送，而不使用 cookie），但我建议生成单独的密钥/令牌对网站的每个消费者。许多不使用 OAuth 的流行公共 API 采用这种方法（例如 Twilio）。