基本上 OAuth2 架构用于第 3 方身份验证和授权。在这种机制中,凭证保持安全,并且在一切都在令牌上工作时不会传递!但是您也可以使用它来隐式地为您自己的身份验证工作。
在您的情况下,首先当您点击“ /oauth/token ”(默认端点)以及客户端秘密和客户端 ID 以及其余用户凭据时,算法会检查数据库中的用户详细信息并匹配存在的秘密和 ID在请求的标头中。如果一切顺利,它将生成一个承载类型 - 访问和刷新令牌,并将这些令牌存储在数据库的不同集合中。此特定用户映射到这些令牌,并且只能使用它们访问 /api。不需要用户凭据. 如果您使用 MongoDb 存储和访问存储的令牌,则可以使用 MongoTokenStore。
接下来,您必须配置 WebSecurity/AuthorizationServer/ResourceServer 以检查端点和标头令牌令牌、用户的身份验证和授权,并分别提供对资源的有效令牌访问。
最后,当您拥有有效的访问令牌并使用正确的标头请求访问 api 时,服务器会授予您访问资源的权限!
这是 OAuth2.0 的基本功能。
通常访问令牌的生命周期较短,而刷新令牌的生命周期相对较长。访问令牌过期后,可以使用刷新令牌生成新的访问令牌。如果刷新令牌过期,那么您必须再次点击“ /oauth/token ”api,完成流程循环并再次生成令牌。过期后,当您点击具有现有访问令牌的 api 时,它们将从集合中删除。这是该机制的默认架构,其余您可以根据需要制作自定义类并修改其功能!这种架构非常安全,是一个很好的实践。
截图流程图
检查来自digitalocean的这篇文章。
编辑----
- 就我个人而言,我使用了 MongoDB,我在其中创建了两个集合 - AuthAccessTokens 和 AuthRefreshTokens,即这两个集合的存储位置。访问令牌对象具有关联的 RefreshToken 的 Id,有助于将这两者映射在一起。休息自定义附加信息。也可以使用 TokenEnhancer 添加。因此,除非过期,否则令牌将始终存在于数据库中。用外行的话来说,如果你只关注后端的东西,你总是可以通过点击“ /oauth/token ”来检查你的访问令牌" 具有正确的用户凭据,它将通过从数据库中获取分配的令牌来返回分配的令牌,否则,如果您在第一步生成令牌后正在开发完整堆栈,只需将它们存储在客户端浏览器的本地存储或应用程序中。如果您想故意结束会话,例如在注销中只需从它们各自的集合中删除这些令牌。