2017-09-15 3 views
2

私はIdentityServer4を使用しています。 hereと表示されているGoogle認証ミドルウェアを設定しました。ただし、Googleに登録されたリダイレクトURLは<domain>/signin-googleです。さらに、Googleで認証した後、Googleに登録されているリダイレクトURIが(/signin-google)呼び出された後に、ExternalLoginCallbackエンドポイントが呼び出されることがわかりました。IdentityServer4では、認証後にGoogleミドルウェアが/ signin-googleコールバックをどのように処理しますか?

私の質問は/signin-google/ExternalLoginCallbackの間でどうなりますか?ブラウザが/signin-googleにリダイレクトされてから、アプリケーション/ミドルウェアが最終的に/ExternalLoginCallbackになる前に、Googleミドルウェアのどの方法が起動されますか?

答えて

0

ASP.NET Core Security Github repoを見ると、Google middlewareの実装が見つかります。本質的には、コードをトレースするとGoogleHandlerOAuthHandler<T>から継承し、RemoteAuthenticationHandler<T>を継承していることがわかります。 RemoteAuthenticationHandler<T>には(here)というメソッドがあります。このメソッドは、OptionsオブジェクトのCallbackPathプロパティにあるURLと現在のURLを比較します。これは認証ミドルウェアが、認証プロバイダからリダイレクトされた後にトリガされる方法です(ミドルウェアによって処理されます)。コントローラではありません。ミドルウェアがトリガされると、認証プロセスが再開されます。

すべての外部認証プロバイダのミドルウェアがこの方法で動作します。ミドルウェアがトリガーされると、OAuthHandler内のHandleRemoteAuthenticationというメソッドがトリガーされます。 hereを参照してください。これは、OAuth 2.0 authorization code flow processの2番目の脚をトリガーし、プロセスの最初の脚で得られた1回限りの使用コードがアクセストークンと交換されます。このプロセスは、ExternalLoginCallbackがトリガーされる前に行われます。具体的には、コードがアクセストークンと交換され、いくつかのユーザー情報がGoogleから入手されると、ClaimsPrincipalが作成され、一時的なクッキーが発行されます。デフォルトでは、クッキーの名前はidsrv.externalです。その後、IdentityServer4 Quickstartプロジェクトに表示されるように、ExternalLoginCallbackエンドポイントがトリガーされ、idsrv.externalクッキーが削除され、ClaimsPrincipalに対して新しい認証クッキーが発行されます。

Googleミドルウェアは、Googleに固有の基本クラスの機能をオーバーライドしますが、本質的にすべてのOAuth 2.0/OpenID Connectミドルウェアがこのように機能します。

関連する問題