web-services - RESTful Web 服务的最终用户身份验证

Question

我有一个面向内部的 RESTful Web 服务。有各种客户端应用程序使用该服务，并且客户端应用程序本身也有最终用户。 Web 服务需要根据最终用户身份对请求进行授权。

问题:这里用于验证最终用户身份的典型选项是什么？也就是说，我想对用户进行身份验证，而不是客户端应用程序。 (我不介意验证客户端应用程序是否是该方案的一部分，但最终我需要知道最终用户就是我认为的他或她。)

例如，一种可能的方案是拥有每个客户端的系统帐户，然后让客户端简单地断言用户的身份(例如，在 HTTP 请求 header 中)。因此，我们对客户端应用程序进行身份验证并将用户身份验证委托(delegate)给客户端。不过，我认为这不是一个非常强大的方案，因为它过于依赖于系统帐户凭据的保密。我见过太多通过电子邮件发送系统帐户凭据的例子，因此对这种方法抱有很大的信心。

另一种方法可能是让客户端应用程序在用户登录时使用用户的凭据从 API 获取 token ，然后将该 token 用于后续 API 请求。这样，身份验证是特定于用户的，无需客户端应用程序保留用户名/密码凭据。

无论如何，我想更好地了解我应该在这里考虑的选项范围。

Answer 1

您所描述的“委托(delegate)身份验证”问题是真实存在的。这意味着使用其凭据的“客户端应用程序”可以访问全部用户数据。此访问权限可能会被恶意使用(例如“半受信任”的应用程序收集 api 数据)或因疏忽而使用(例如应用程序意外暴露直接对象引用漏洞 - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References)

最流行的“基于 token ”方案可能是 OAuth2 ( http://oauth.net/2/ )，以及许多网站选择继续使用的前身 OAuth。

OAuth2 有许多作用:

1. 资源所有者(您的情况下的用户)
2. 资源服务器(您的 API)
3. 客户端(您谈论的应用程序)
4. 授权服务器(不清楚在您的案例中由谁或什么人员担任此角色)

基本方案是资源所有者使用其凭据直接向授权服务器进行身份验证。然后，他们会被询问是否想要向某个客户端授予一些信息(可能只是一个持久标识符，或者是您的 api 公开的信息的描述)。当他们接受“身份验证代码”发送到客户端时，他们使用该代码(与他们自己的凭据相结合)来接收“访问 token ”。然后可以使用此访问 token 对资源服务器进行身份验证(资源服务器可以根据授权服务器检查其真实性)。

通常的使用方式是授权服务器和资源服务器由同一实体拥有和管理(例如google和facebook将履行此角色)，然后独立管理客户端。

该方案还可以在组织内部使用，无需“显式授权”，在从 API 发布任何数据之前，该方案仍然至少可以确认特定的最终用户是否存在。