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

Question

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

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

例如，一种可能的方案是拥有每个客户端的系统帐户，然后让客户端简单地声明用户的身份（例如，在 HTTP 请求标头中）。因此，我们对客户端应用程序进行身份验证并将用户身份验证委托给客户端。不过，我不认为这是一个非常强大的方案，因为它过于依赖于保持系统帐户凭据的机密性。我已经看到太多人们通过电子邮件发送系统帐户凭据的例子了，我对这种方法没有信心。

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

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

Answer 1

您用“委托身份验证”描述的问题是真实存在的。这意味着使用其凭据的“客户端应用程序”可以访问整个用户数据。这种访问可以被恶意使用（例如“半可信”应用程序收集 api 数据）或疏忽（例如应用程序意外暴露直接对象引用漏洞 - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References）

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

OAuth2 有许多角色：

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

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

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

该方案也可以在没有“明确授权”的情况下在组织内部使用，它至少可以在从 api 发布任何数据之前确认特定最终用户存在。