因此，我正在创建多个 REST API，并且我想要一个用于所有这些服务的单一身份验证服务器 (API)，以避免在每个新应用上创建多个登录。
什么技术最适合这个？ oauth 服务器？
我还希望它能够根据 API 分离用户并根据需要进行共享。但始终让单个身份验证服务器执行其操作，这样我就不必每次都创建单独的登录系统。
对于使用 API key 获取数据的机器，我还需要“非用户输入”访问权限。但我猜用户只需要一个界面来生成第一个消费者 key ，然后在他们的应用程序中使用它。基本上是没有过期的 token ？
我设想的流程是这样的:
- API 消费者调用 API 代理，API 代理调用 Auth API 来授权用户并返回访问 token ，访问 token 存储在资源 API 服务器之一上
- API 消费者调用现在调用资源服务器的 API 代理，检查有效的访问 token 并返回数据，但这次它不调用 Auth API，所以我不必在内部为每个请求进行两次调用。
这是一个好方法吗？
除此之外，我需要我的实际网站在没有用户登录/交互的情况下使用 API，除了以某种方式浏览以访问 API，oauth 仍然可以这样做吗？如何在 API 上验证我自己的公共(public)应用程序/网站？我应该预先创建没有有效期的 oauth 访问 token 吗？
我不打算让用户使用 facebook、google 帐户等登录。我只想让我公司的用户在多个服务上进行全局登录，并将 API 使用者的登录信息存储在一个地方。
Oauth、SSO/CAS？
最佳答案
您可以使用 OAuth20。它的主要思想正是您所需要的。您的用户将传递一次他们的用户名和密码，然后您的 API 消费者应用程序将从授权服务器获取访问 token (类型=密码)。对您的 API 的所有后续调用都将使用访问 token 。您可以使用不同的客户端凭据注册不同的 API 消费者应用程序。每次生成用户访问 token 时都应使用这些客户端凭据，即生成的用户访问 token 将为特定的 API 消费者应用程序颁发。此外，您的 API 消费者应用程序可以获得访问 token (type=client_credentials)，以便使用与特定用户无关的 API 的某些部分。每个 API 消费者应用程序可能有不同的作用域，这些作用域绑定(bind)到 API 的不同部分。换句话说，范围定义了您的 API 的哪一部分可供 API 使用者应用程序使用。关于 token 过期，您可以为 API 消费者应用程序访问 token 使用更长的时间，并为用户访问 token 使用刷新 token 机制。有关其他详细信息，请查看 OAuth20 规范 - https://www.rfc-editor.org/rfc/rfc6749 .
关于api - 多个 API 的授权服务器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22648022/