1👍
I would suggest using a third-party application, like django-allauth. You can simply disable creating local accounts, and enable a single custom social provider that interacts with your OAuth2.0 authorization server.
As noted here, the process of creating your own custom OAuth provider isn’t documented, but shouldn’t be too difficult.
Once I get the access token after the user login where is it safe to keep the access token?
Allauth will store the access token in the database. If you want to put it in the session too, you can, but there’s no point unless you want the client to make requests to the resource server directly.
Every time the user makes a request I would check the AT I’m keeping, if the verification is OK our app responds with the view, otherwise the user is redirected to the login. Is this flow correct or am I not understanding how this integration would work?
That’s fine. If your authorization server has no way to invalidate issued access tokens, though, you can just assume that the access token is good up until the expiration date.
What would happen in the case the user is given more permissions but I hold an old token? How do I handle these cases?
Just use the access token normally. If the resource server indicates that it’s invalid, prompt the user to log in again. You will get a new access token for that user that reflects their current permissions.