我正在为一组 RESTful Web 应用程序的用户开发一个内部身份验证系统。我们的目的是，用户应该能够通过 Web 表单登录一次，并能够适当访问我们域中的所有这些 RESTful 应用程序，这些应用程序可能分布在跨许多服务器的私有云中。 （我已经了解，拥有单个经过身份验证的会话与纯粹的 RESTful 方法并不相符，但这是可用性要求。）
应用程序本身将用多种编程语言编写，因此需要一种与语言无关的方法。有人向我建议，我们可以使用 OpenID 或 OAuth 或类似的框架来处理身份验证，但我的理解是，这些框架适用于第三方服务，而不是用于在我们内部系统上共享数据的第一方服务。在这种情况下，我们可能有一个中央提供商服务，所有其他应用程序都被视为第三方（或依赖方）。
问题：
- OpenID/OAuth是否适合第一方服务之间的认证？
- 如果是这样，如何建议人们为此用例设置身份验证？
- 用户是否必须向他们想要使用的每个第一方服务器授予单独的权限，就像他们需要向任何第三方服务器授予单独的权限一样？我认为这违反了通过单点登录访问所有第一方服务的要求。
- 是否有支持此第一方用例的网站的好例子？
- 对于这个第一方用例来说，什么是一个好的替代框架？
SSO 服务不需要 OAuth。
正如您所知，OAuth 的主要用途/优点是授予第三方应用程序访问权限，以受控方式访问/使用您的资源。
与其拥有 OAuth 所需的身份验证/授权服务器，不如在所有 API 中使用单一登录服务。 OAuth 访问令牌与您需要的完全不同。
据我了解，您可以拥有类似于 OAuth 的东西，您的服务器可以将令牌出售给应用程序。 （我假设它是一个完全内部的系统，因此令牌不能被滥用）。
所以基本上我的建议是：
- 当应用程序尝试访问第一个 API 时，它会被重定向到 Web 表单。
- 用户输入凭据并被带到数据库进行验证。让有一个服务为用户/应用程序生成令牌
- 下一个 API 访问请求将使用该令牌发出 - 该令牌唯一标识该应用程序
- 根据您需要的安全级别，您可以使用 HMAC 签署一些文本并将其作为令牌发送，或者如果其完全内部，则只需为应用程序/用户生成唯一标识符并将其发送到其他 API
- 收到令牌后，每个服务首先使用令牌调用主服务器，并在内部获取相应的客户/用户 ID 并执行所需的功能。
简而言之，将登录+令牌生成+令牌验证分离到不同的模块中。所有 API 都应使用此模块进行登录/令牌验证。
我在这里建议的工作方式类似于 OAuth，但所有安全方面都已被剥离，因为您想在私有云中使用它。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
