2017-04-21 12 views
0

IdentityServer4とOIDC-Clientを使用するSPA環境では、複数の外部プロバイダーで以下を実行する最も安全なアプローチは何ですか?OIDCクライアントとIdentityServer4を使用して内部IDプロバイダートークンを使用して外部IDプロバイダートークンを交換する

ユーザーがGoogleにログインすると、内部システムにログインして新しいクレームを作成する必要があります。これはサードパーティのコールバック後のサーバー側で行わなければなりません。 SPAでこれを行うためにIdentityServer4内で最も安全な設定は何ですか?

フロー:Googleが戻っSPAにリダイレクトするSPAでグーグルに

  1. ユーザログ(oidcManager.signinRedirectを呼び出す)
  2. バックにJWTを送信(CAL新しいOidc.UserManager()signinRedirectCallback。) IdentityServer4(ただし、どのメカニズムを使用するのですか?) ユーザが内部システムに存在する場合、OIDCManagerが管理できるカスタムクレーム(新しいものを置き換える)で新しいJWTを返します。 ユーザーが内部システムに存在しない場合、リソース所有者資格フローが引き継ぐログインページにリダイレクトします。

#3の場合、自分のエンドポイントをローリングする代わりに、IdentityServer4がすでに提供しているものを使用したいと思います。このシナリオは簡単にサポートされていますか?

は基本的に、私はIdentityServer4は、このシナリオを処理する方法を確認してくださいこれを完了する必要がなく、:

new Oidc.UserManager().signinRedirectCallback().then(function (externalUser) { 
    //TODO: pass externalUser to IdentityServer4 endpoint where it's exchanged for internal user 
    window.location = "../Spa/Index"; 
}).catch(function (e) { 
    console.error(e); 
}); 

ログイン流れに加えて、複数の外部プロバイダーとトークンリフレッシュを行うための最も安全なアプローチものです。私は自分の内部トークンが切れた場合に備えて定期的に外部トークンをリフレッシュする必要があると仮定しています。

答えて

0

私たちはユーザーがGoogleとFacebookからログインできるようなプロジェクトを持っています。私たちはIdentityServerを介してGoogleとFacebook SignInを追加し、クライアントアプリケーションがリソースサーバー(API)に送信するaccess_tokenの中にIDと電子メールアドレスを格納しているため、リソースサーバーはログインしているユーザーを知ります。

したがって、IdentityServer4に組み込まれたGoogle SignInを使用して、リソースサーバー(API)に詳細を送信することをお勧めします。

関連する問題