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

我有两个节点服务器。一个为网站服务，一个为RESTfulAPI服务，后者为网站背后的数据提供动力

当用户登录到网站时，将创建一个会话。然后，这允许我根据用户是否登录，向用户提供正确的HTML

我的API还需要识别和授权某些端点的用户。但是，由于API是在不同的服务器上提供的（与创建登录会话的服务器不同），因此我无法重用该会话数据。此外，我希望RESTful API是公共的，以这种方式重新使用会话数据可能会防止这种情况。我所说的公开，是指从长远来看，我希望允许外部开发人员与他们的API请求进行交互并授权他们的API请求。有些端点需要授权（例如

将
放在
用户
资源上），而有些端点应该是免费的（公共的；例如
用户
资源上的
获取
）

这是我的第一个RESTful API，我以前从未以这种方式处理过身份验证。考虑到这些细节，我应该如何准确地设计我的身份验证层

我对会话令牌和OAuth有一个非常简单的了解，但是如果您有一个涉及其中任何一个的解决方案，我希望详细解释一下这些东西是如何结合在一起创建身份验证层的。任何链接到资源，以帮助我学习各种技术也将不胜感激
 我将调用您的Web服务器A和数据服务B。一个简单的方案是使用私钥在B上注册A。然后，从A到B（通过https）的请求可以包含带有私钥的身份验证头（），这将解锁API的“私有”功能。如果在不使用或使用假私钥的情况下调用，这些函数将返回HTTP 403 Forbidden或其他内容（）。
请尽可能将两种身份验证方法分开。大多数对API的调用不会通过浏览器进行，在代码中管理HTTP客户端中的会话是一件非常痛苦的事情。对于通过浏览器的web应用程序，基于会话的方法是正确的

对于API，有两种常用的添加身份验证的方法：HTTP basic auth over SSL和OAuth 2。尽管在您的情况下，为特定的端点选择性地启用简单的HTTP基本身份验证（确保使用SSL）可能是一种方法。您可以让您的用户使用其正常凭据登录（浏览器将对其进行一些缓存，并在会话剩余时间的第一次成功身份验证后自动发送，而不使用cookie），但我建议为网站的每个消费者生成一个单独的密钥/令牌对。许多不使用OAuth的流行公共API采用这种方法（例如Twilio）