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