我有一个面向内部的RESTful Web服务。有各种使用该服务的客户端应用程序，客户端应用程序本身具有最终用户。 Web服务需要根据最终用户身份授权请求。
问题：此处验证最终用户的典型选项有哪些？也就是说，我想验证用户，而不是客户端应用程序。 （我不介意验证客户端应用程序是否是该方案的一部分，但最终我需要知道最终用户是我认为他或她的人。）
例如，一种可能的方案是拥有每个客户端系统帐户，然后让客户端简单地断言用户的身份（例如，在HTTP请求头中）。因此，我们验证客户端应用程序并将用户身份验证委派给客户端。不过，我认为这不是一个非常强大的方案，因为它过分依赖于保持系统帐户凭据的秘密。我见过很多人通过电子邮件发送系统帐户凭据的例子，对这种方法非常有信心。另一种方法可能是让客户端应用程序在用户登录时使用用户的凭据从API获取令牌，然后将该令牌用于后续API请求。这样，身份验证是特定于用户的，无需客户端应用程序挂起用户名/密码凭据。
无论如何，我想更好地了解我应该考虑的各种选择。
答案 0 :(得分：2)
您使用“委派身份验证”描述的问题是真实的。这意味着使用它的凭据的“客户端应用程序”可以访问整个用户数据。可以恶意使用此访问权限（例如，“半信任”应用程序收集api数据）或疏忽（例如，应用程序意外暴露直接对象引用漏洞 - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References）
最普遍的“基于令牌”方案可能是OAuth2（http://oauth.net/2/），以及许多网站选择继续使用的前兆OAuth。
OAuth2有许多角色：
基本方案是资源所有者使用授权服务器直接使用其凭据进行身份验证。然后询问他们是否要向某个客户授予一些信息（可能只是一个持久的标识符，或者由api公开的信息的描述）。当他们接受'auth code'时，会发送给客户端，他们使用它（与他们自己的凭证相结合）来接收'访问令牌'。然后，可以使用此访问令牌对资源服务器进行身份验证（可以检查它与授权服务器的真实性）。
通常使用它的方式是授权服务器和资源服务器由同一实体拥有和管理（例如google和facebook将履行此角色），然后客户端被独立管理。
该方案也可以在组织内部使用而没有“显式授权”，在从api发布任何数据之前，该授权仍然至少可以确认特定的最终用户。