我们正在为我们的Web应用程序构建一个新的RESTful API。此API将为我们的移动应用程序，我们的Web应用程序和授权客户提供服务。
我们正在使用Apigility构建API并正在使用它提供的OAuth2实现。
目前，我们的Web应用程序依赖于users表，并为每个用户分配了权限。这些用户只需使用Web表单登录，然后存储会话并在访问时检查适当的权限。
我们希望能够验证API访问权限（例如我们的网络应用程序和授权客户），因此不会发生对API的未授权访问。但是，我们还希望在用户级别授权权限，因此也必须进行某种用户身份验证。
对API的任何授权访问都可能使用不同的用户，因此依赖每个客户端的单个用户将无法工作，尤其是因为权限是基于每个用户的。我们也不希望任何用户在没有事先验证的情况下使用API，因此希望避免将每个用户作为客户端添加到OAuth2。
使用API对Web应用进行身份验证，两位用户使用它：
UserA具有用户管理权限
UserB没有用户管理权限
因此，UserA可以POST到/users并获得200 OK而UserB可以获得403 Forbidden。
我们已经创建了一个示例应用程序，并已成功为高级客户端使用OAuth2设置身份验证，并可以按预期进行调用。但是我们无法基于此为我们的用户创建授权模型。
我们添加了一个自定义HTTP标头，其中包含在对/user/login进行身份验证调用后提供的用户令牌。但我们不确定这是否是正确的方法。
我们如何验证高级客户端（例如我们的网络应用程序或授权客户），然后根据实际使用系统的用户授权访问？
答案 0 :(得分：2)
您可以选择几种方式：
令牌级权限
您可以为每个用户帐户提供不同的令牌，并将权限绑定到令牌。这会冒错误令牌与错误用户混在一起的风险。然而，这还具有不必维持用户＆lt; - ＆gt;令牌关系的优点，因为在令牌级别确定了许可。你如何决定生成哪个令牌可能很棘手。
用户级权限
您可以将用户帐户绑定到令牌，然后可以为该用户授予读/写权限。这降低了用户在链接时出现错误令牌的风险。使用此方法，您可以对所有用户帐户使用相同的令牌生成方法，因为令牌不知道权限，但允许他们“访问”API（从而防止未经授权的访问）。
我故意避免提及特定类型的身份验证令牌，因为这两个概念可以应用于网络上的大多数热门选择（基于令牌，基于OAuth）。
答案 1 :(得分：0)
OAuth没有concept of Identity。
您应该考虑使用OpenID Connect，它是Oauth 2.0之上的个人资料。