当前，我们已经有一个应用程序，它是前端和后端分离的应用程序，前端是Web应用程序（SPA），后端是Web API。
对于该应用程序，我们已经使用了注册，用户登录，用户角色，角色权限，用户检查和权限检查。
现在，我们正在集成外部身份服务（开放ID和Oatuh2），但我误解了外部身份服务的身份验证和授权
问题1：是的，我可以使用外部身份服务进行登录并获得访问令牌，但是在那之后，我仍然需要在应用程序中维护用户，因为对于企业而言，我需要知道是谁创建订单，谁操作了订单等等……那么，用户系统我在应用程序中要做的事情，我仍然需要做，它可以纠正我的工作吗？
问题2：对于授权，我仍然需要在应用程序中维护自己的用户角色，角色权限和权限检查，如果是这样，身份服务（OAuth2）的权限是什么？我的应用程序中的OAuth2授权和权限模块有什么区别？
答案 0 :(得分：2)
第一件事，OAuth 2.0没有定义如何处理权限。它定义了一种获取访问令牌的方法。访问令牌是您的API接受作为访问授权的机密（例如：-将它们与基本身份验证标头进行比较。现在您将收到令牌）。
如何进行令牌验证？您有两个主要选择。您可以对令牌发行者（身份服务）进行令牌自省（RFC7662）。响应将包含有效负载，其中可能包含经过身份验证的最终用户和令牌到期详细信息。
或者，如果访问令牌采用JWT格式（RFC7519），则您的API可以查找以JWT发送的特定声明（您将进行JWT验证，其中包括JWT签名验证）。声明应包括最终用户以及到期明细。
无论哪种方式，都可以在提取所需信息之后调用您的权限逻辑。
关于身份验证，它是使用OpenID Connect和ID令牌构建的。身份验证将在客户端（您的情况下为SPA）中进行。这与API调用无关。
关于权限，用户和角色映射。如果使用内置的用户数据存储，则需要在外部身份服务和内部存储之间进行用户映射。否则，无法将通过令牌（如答案的第一部分中所述）接收到的用户数据与内置令牌相关联。这与OAuth 2.0和OpenID Connect无关。
例如，如果在内部存储中找不到该用户，则可以假定该用户属于受限用户角色。另外，您可以在首次收到此类数据时（在验证令牌时）将该用户添加到内部系统中。以后，可以有一个过程为登机的用户分配权限。确切的实现细节取决于您的情况。