如何使用OpenID或OAuth进行内部第一方身份验证? [英] How to use OpenID or OAuth for internal first-party authentication?

问题描述

我正在为一组RESTful Web应用程序的用户开发一个内部身份验证系统.我们的意图是，用户应该能够通过Web表单登录一次，并具有对我们域中所有这些RESTful应用程序的适当访问权限，这些应用程序可以分布在许多服务器的私有云中. (我已经知道，只有一个经过身份验证的会话并不符合纯RESTful方法，但这是可用性的要求.)

I am working on an internal authentication system for users of a set of of RESTful web applications. Our intention is that a user should be able to sign-on once via a web form and have appropriate access to all these RESTful applications in our domain, which may be distributed in a private cloud across many servers. (I understand already that having a single authenticated session is not aligned with a pure RESTful approach, but this is a usability requirement.)

应用程序本身将使用多种编程语言编写，因此需要一种与语言无关的方法.我建议我们可以使用OpenID或OAuth或类似的框架来处理身份验证，但我的理解是，这些服务旨在用于第三方服务，而不是将在我们的内部系统上共享数据的第一方服务.在这种情况下，我们可能拥有一个中央提供者服务，而所有其他应用程序都被视为第三方(或依赖方).

The applications themselves will be written in a variety of programming languages so a language-neutral approach is required. It was suggested to me that we might use OpenID or OAuth or a similar framework to handle the authentication but my understanding is that these are intended for third-party services and not the first-party services that would share data on our internal system. In this case, we might have a central provider service with all the other applications treated as third parties (or relying parties).

问题:

1. OpenID/OAuth是否适合在第一方服务之间进行身份验证?
2. 如果是这样，将建议如何为此用例设置身份验证?
3. 用户是否不必像要向任何第三方服务器授予单独权限一样，向他们要使用的每个第一方服务器授予单独权限?我认为这会违反访问所有第一方服务的单一登录的要求.
4. 是否有很好的网站示例支持此第一方用例?
5. 对于此第一方用例而言，什么是一个很好的替代框架?

推荐答案

您不需要OAuth即可获得SSO服务.

You do not need OAuth for SSO services.

众所周知，OAuth的主要用途/优点是授予对第三方应用程序的访问权限，以便以受控方式访问/使用您的资源.

The primary use/advantage of OAuth is, as you know already, granting access to a 3rd party app to access/use your resource in a controlled manner.

与其拥有OAuth所需的身份验证/授权服务器，不如不跨所有API使用单一登录服务. OAuth访问令牌与您所需的令牌完全不同.

Rather than having an authentication/authorization server that you would need for OAuth, why not use a single log in service across all your APIs. An OAuth access token is totally different from what you need.

据我了解，您可以拥有类似于OAuth之类的东西，您的服务器可以向应用程序出售令牌. (我假设这是一个完全内部的系统，因此不能滥用令牌).

As far as I understand, what you can have is something like OAuth in a way that your server vends out tokens to the app. (I'm assuming that it's a totally internal system, so tokens cannot be misused).

所以我基本上建议的是:

So basically what I'm proposing is:

1. 当应用尝试访问第一个API时，会将其重定向到网络表单.
2. 用户输入凭据，并被带到DB进行验证.让某项服务为用户/应用生成令牌
3. 将使用该令牌提出下一个API访问请求-令牌唯一标识应用程序
4. 根据您需要的安全级别，您可以使用HMAC签名一些文本并将其作为令牌发送，或者如果它的内部完全只是为应用程序/用户生成唯一的标识符并将其发送给其他API，则可以使用
5. 接收到令牌后，每个服务首先使用令牌调用主服务器，并在内部获取相应的客户/用户ID，并执行所需的功能.

简而言之，将登录名+令牌生成+令牌验证分为不同的模块.所有API都应使用此模块进行登录/令牌验证.

In short separate the login + token generation + token verification into a different module. All APIs should use this module for login/token verification.

我在这里提出的功能类似于OAuth，但由于要在私有云中使用它，因此所有安全方面的内容都已精简.

What I have proposed here works like OAuth but all security aspects have been stripped down since you want to use it in a private cloud.

这篇关于如何使用OpenID或OAuth进行内部第一方身份验证?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！