Oauth2での外部ログイン

Question

私はDjangoの認証を使ってDjangoアプリケーションを開発しています。反対側にはすでにすべてのユーザーとその権限が登録されているOauth2.0サーバーがあります。今私の目標は、DjangoアプリケーションをOauth2.0サーバーと統合して、ユーザーを自分で管理する必要がないようにすることです。これは、ユーザーが私たちのアプリにログインしたいときに、Oauth2.0ログインサイトにリダイレクトされ、その後正常にログインするとアプリケーションのホームにリダイレクトされるようにします。

私はOauth2.0の仕組みを理解していると思いますが、他には見つけられない質問がいくつかあります。

私が説明しているシナリオは可能ですか？あなたのアプリケーションに登録する必要がなくなり、サードパーティの認証サーバーがアプリケーションへのアクセスを提供するか否かのようになります。

ユーザートークンの後にアクセストークンを取得したら、どこにアクセストークンを保存しても安全ですか？私はセッション変数としてATに保存して、エンドユーザのセッションをDjangoアプリケーションの外部にある自分のアカウントにリンクすることができると考えていました。

ユーザーがリクエストするたびに、私が確認しているATを確認します。確認がOKであれば、アプリケーションはビューに応答します。そうでなければ、ユーザーはログインにリダイレクトされます。この流れは正しいのですか、この統合がどのように機能するか理解していませんか？

ユーザーにさらに権限が与えられても、古いトークンを保持している場合はどうなりますか？これらのケースをどうやって処理するのですか？

Answer 1

django-allauthのようなサードパーティのアプリケーションを使用することをお勧めします。ローカルアカウントの作成を無効にするだけで、OAuth2.0認証サーバーと対話する単一のカスタムソーシャルプロバイダを有効にすることができます。

hereのように、独自のカスタムOAuthプロバイダを作成するプロセスは文書化されていませんが、それほど難しいものではありません。

ユーザートークンの後にアクセストークンを取得したら、どこにアクセストークンを保存しても安全ですか？

Allauthはアクセストークンをデータベースに格納します。それをセッションに入れることもできますが、クライアントがリソースサーバーに直接要求を出さないようにする必要はありません。

ユーザーがリクエストするたびに、私が確認しているATを確認します。確認がOKであれば、アプリケーションはビューに応答します。そうでなければ、ユーザーはログインにリダイレクトされます。この流れは正しいのですか、この統合がどのように機能するか理解していませんか？

これは問題ありません。認証サーバーが発行されたアクセストークンを無効にする方法がない場合でも、有効期限までアクセストークンが有効であると仮定できます。

ユーザーにさらに権限が与えられても、古いトークンを保持している場合はどうなりますか？これらのケースをどうやって処理するのですか？

アクセストークンを正常に使用してください。リソースサーバーが無効であることを示す場合は、ユーザーに再度ログインするように要求します。そのユーザーの現在のアクセス許可を反映する新しいアクセストークンを取得します。