OAuth 2.0范围作为集中授权的服务标识符？

Question

我即将为我们公司的认证和授权编写中央服务，我们称之为C-AAA。

此中央服务包含所有用户凭据。它还配备了基于Web的用户界面，管理员可以将不同服务（即Web应用程序）的访问权限分配给特定用户。这些应用程序现在应该使用标准化方法来询问C-AAA是否应该为用户提供访问权限。

我想到的第一个想法是使用OAuth 2.0，因为这样我们就可以轻松地为第三方应用程序，移动应用程序等提供auth接口。

我想象的过程如下：

1. 用户调用安全的Web应用程序（“SecApp”）。
2. SecApp会检查现有的有效会话（在应用程序中）。
3. 如果不存在会话，则使用OAuth建议的客户端密钥和客户端ID调用C-AAA。此外，应用程序为请求设置了一个范围，即她自己的名字“secapp”。如果客户端ID和密码正确，则返回验证码。
4. 使用auth代码，用户将被重定向到C-AAA上的登录名。
5. 用户向C-AAA提供他/她的凭据。
6. C-AAA验证它们并检查请求的范围是否与用户相关的角色相对应。 （在这种情况下，“secapp.user”和“secapp.admin”可能被定义为有效权限。）
7. 仅当两个条件均为真时，才会授权用户并生成访问令牌。
8. 访问令牌将返回到SecApp应用程序。
9. 从C-AAA获取有关用户个人数据和应用程序权限（用户/管理员）的信息。
10. 用户信息存储在SecApp应用程序中的会话变量中，并根据返回的角色授予访问权限。

OAuth specification并未对范围的使用说太多。因此，我在问：

这是对OAuth 2.0标准的合法使用吗？如果不是，我会推荐哪种方法？ （我真的不想重新发明轮子，因此坚持标准。）

附注：C-AAA使用Symfony2实现，使用FOSUserBundle和FOSOAuthServerBundle。

提前感谢您的回答！

Answer 1

这看起来像OAuth的一个很好的用例。
首先，C-AAA应用程序不仅应该存储凭据，还应该存储范围。

现在看看你提到的要点，我想建议一下流程的一个变化。

在第3步中 - ＆gt;当用户点击SecureApp端点并且没有打开活动会话时，用户必须登录并提供凭据。

登录应该是C-AAA中央身份提供商的一项功能。因此，用户从SecureApp重定向到他登录的C-AAA门户，并且当登录尝试成功时，客户端获得访问令牌。此登录和访问令牌生成都在客户端和C-AAA模块之间发生。 {注意当我们通过Facebook登录时弹出窗口如何打开} 因此，一旦登录C-AAA就会向客户端返回一个令牌（这不包含客户端密码）。这非常像SSO。客户端的访问令牌包含有关用户的信息以及允许的作为加密数据的范围。

客户端现在使用此访问令牌命中组织中的任何端点（直到令牌有效）。 API在内部调用C-AAA来验证用户身份并检查他是否有权访问所请求的操作。

此方法的优点是您可以随时在组织内创建更多端点，并确保它们对C-AAA模块提供的访问令牌进行身份验证。

我记得在这里写了一个更详细的答案 - How would an efficient OAuth2.0 server / provider work?

Answer 2

我认为决定用户是否可以根据他的“角色”访问应用程序不是C-AAA的角色。

  

scope参数用于指示客户端

请求的权限列表

必须要求应用程序（即scope参数的角色）访问用户的“角色”，并在验证C-AAA凭据后，使用此信息来决定是否允许创建会话在应用程序级别或拒绝用户访问。