Web services OAuth 2.0作用域作为集中授权的服务标识符？

我将要为我们公司的身份验证和授权编写一个中心服务，我们称之为C-AAA

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

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

我认为过程如下所示：

安全web应用程序（“SecApp”）由用户调用

SecApp检查现有的有效会话（在应用程序内）

如果已经不存在会话，它将使用客户机机密和客户机id调用C-AAA，正如OAuth所建议的那样。此外，应用程序为请求设置了一个作用域，即她自己的名字“secapp”。如果客户端id和密码正确，则返回身份验证码

使用身份验证代码，用户被重定向到C-AAA上的登录

用户向C-AAA提供其凭据

C-AAA验证它们，并检查请求的作用域是否与用户关联的角色相对应。（“在这种情况下，secapp.user”和“secapp.admin”可能被定义为有效权限。）

仅当这两个条件都为真时，才授权用户并生成访问令牌

访问令牌将返回给SecApp应用程序

有关用户个人数据和应用程序权限（用户/管理员）的信息从C-AAA获取

用户信息存储在SecApp应用程序内的会话变量中，并根据返回的角色授予访问权限

对于作用域的使用，本文没有说太多。因此，我要问：

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

旁注：C-AAA是使用Symfony2实现的，使用FOSUserBundle和FOSOAuthServerBundle

---

提前感谢您的回答

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

scope参数用于指示客户端请求的权限列表

---

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

这看起来是OAuth的一个很好的使用案例
首先，C-AAA应用程序不仅要存储凭证，还要存储作用域

现在看看你提到的几点，我想建议在流程中做一个改变

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

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

---

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

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

---

我记得在这里写了一个更详细的答案-

“API的内部调用C-AAA来验证用户并检查他是否有权访问请求的操作”：我会说API验证令牌（通过调用C-AAA，但这只是一个选项），并根据用户id和令牌的范围接受/拒绝请求（这不需要C-AAA）。我的意思是a和a的单个模块。这是任何REST API都可以连接的。谢谢@divyanshm，你的评论非常有用。Jasper：对我来说，重要的是，C-AAA是系统中唯一保存用户数据实体的部分，并且连接的应用程序的编码工作保持在最低限度。（我想重复使用相同的简化代码段，仅将作用域和可能的附加应用程序角色作为参数，以检查用户在应用程序方面的权限。）因此，我将尝试实现DivYashm的方法。