我正在通过Django的auth与用户一起开发Django应用程序，另一方面，有一个Oauth2.0服务器已经注册了所有用户及其权限。我现在的目标是将Django应用程序与Oauth2.0服务器集成，因此我们不必自己管理用户。这样，当用户想要登录我们的应用程序时，他们会被重定向到Oauth2.0登录站点，然后在他们成功登录后重定向到我们应用程序的主页。
我想我理解Oauth2.0是如何运作的，但我有几个问题我无法在其他任何地方找到。
我描述的情景是否可能？因为用户不再需要在我们的应用程序中注册，第三方Auth服务器将提供对我们的应用程序的访问权限。
一旦我在用户登录后获得访问令牌，那么保持访问令牌是否安全？我以为我可以将AT保存为会话变量，以便将最终用户的会话链接到我的Django应用程序外部的帐户。
每次用户提出请求时，我都会检查AT保持，如果验证结果正常，我们的应用会响应视图，否则用户将被重定向到登录状态。这个流程是正确的还是我不理解这种整合是如何工作的？
如果用户获得更多权限但我持有旧令牌，会发生什么情况？我该如何处理这些案件？
答案 0 :(得分：1)
我建议使用第三方应用程序，例如django-allauth。您只需禁用创建本地帐户，并启用与您的OAuth2.0授权服务器交互的单个自定义社交提供程序。
如上所述[{3}}，创建自己的自定义OAuth提供程序的过程尚未记录，但不应过于困难。
在用户登录后获取访问令牌，在哪里可以安全地保留访问令牌？
Allauth会将访问令牌存储在数据库中。如果你想把它放在会话中，你可以，但除非你希望客户端直接向资源服务器发出请求，否则没有意义。
每次用户发出请求时，我都会检查AT我是否保留，如果验证结果正常，我们的应用会响应视图，否则用户将被重定向到登录状态。这个流程是正确的还是我不理解这种集成是如何工作的？
没关系。但是，如果您的授权服务器无法使已颁发的访问令牌无效，您可以假设访问令牌在到期日期之前是好的。
在用户获得更多权限但我持有旧令牌的情况下会发生什么？我该如何处理这些案件？
只需正常使用访问令牌即可。如果资源服务器指示它无效，则提示用户再次登录。您将获得反映其当前权限的该用户的新访问令牌。