我想在我们的基础架构上实现一个新的基于 REST 的API ，而OAuth似乎是要走的路。
对于我们的实现，首先只有服务器到服务器的访问，这将是完全不受限制的。我相信这被称为两条腿授权。
稍后，我们希望允许浏览器使用 API，这将使我们的授权变成三足。
是否有一个很好的起点来实施这一点？我们如何才能完全授权服务器并为每个用户添加受限授权？
OAuth 规范在这些场景中并没有真正的帮助，但我相信这意味着我们需要为服务器到服务器的访问创建一个永不过期的会话，然后为仅限用户的 API 添加具有有限访问权限的正常会话。
我希望找到更多信息的起点，让我知道！
OAuth 适合我吗？我只是在寻找一个经过身份验证的请求系统，并且这种场景中只存在消费者和服务提供者。终端用户不进来玩！
是的，OAuth 可能适合你。
实际上有两种 OAuth 规范，三足版和两足版。三足版是最受关注的，不是你想用的。
好消息是 2-legged 版本完全符合您的要求，它允许应用程序通过共享密钥授予对另一个应用程序的访问权限（非常类似于 Amazon 的 Web 服务模型，您将使用 HMAC-SHA1 签名方法）或通过公钥/私钥系统（使用签名方法：RSA-SHA1）。坏消息是，它的支持还不如 3-legged 版本，所以你现在可能需要做更多的工作。
基本上，2-legged OAuth 只是指定了一种“签名”（计算散列）几个字段的方法，这些字段包括当前日期、一个称为“nonce”的随机数以及您的请求参数。这使得模拟对您的 Web 服务的请求变得非常困难。
OAuth 正在缓慢但肯定地成为这类事情的公认标准——如果你接受它，从长远来看，你会得到最好的结果，因为人们可以利用各种可用的库来做到这一点。
它比您最初想要的要复杂得多 - 但好消息是很多人在它上面花了很多时间，所以您知道您没有忘记任何东西。一个很好的例子是，最近 Twitter 发现社区目前正在努力弥补的 OAuth 安全漏洞。如果您发明了自己的系统，那么您必须自己解决所有这些问题。
祝你好运！
请记住区分身份验证和授权。在某些地方，我相信 OP 将两者混合在一起。
例如，一旦服务器对某人进行身份验证，它通常会显式或隐式（使用 cookie）提供身份验证令牌，以便后续请求已经获得授权。
凭据的持续时间取决于服务器。计划凭据将在某个时候超时是明智的。只需让客户端服务器准备好在收到“授权过期”错误响应时重新验证自己。
您不想尝试提供“永不过期”的会话，因为：
一切都会在某个时候到期。例如，如果客户端服务器断电或重新启动，它如何能够再次开始访问应用程序？
你正在创建一个不灵活的系统。他们往往更频繁地打破。
OAuth 最终将难以满足我们的需求。我决定采用 Amazon S3 的身份验证方案，仅仅是因为它更适合我们的模型。
感谢您帮助找到答案..