リダイレクトのないIdentityServer4

Question

認証サービスとしてIdentityServer4を実装しています。

これを使用するクライアントは角度アプリです。私が見たすべての例から、クライアントはIDサーバ上でホストされたページにリダイレクトされ、後でクライアントに返されます。

ユーザーエクスペリエンスのため、私はいつも自分のページにユーザーを残したいと思います。したがって、これは2つの質問につながります。

1. サイト内のDIVまたはiframeにIDサーバーのUIを表示することはできますか。私はiframeが少し眉をひそめていると思いますか？

2. 上記が不可能な場合、ログインUIはIDサーバーではなくクライアントアプリケーションでホストできますか？

は、私はそれがUXグループへの質問の多くはであると仮定し、私はサイト内の内のユーザーを維持することは、それらを完全にリダイレクトするのではなく、より優れたユーザーエクスペリエンスにつながるだろうと思っているでしょうか？

おかげ

Answer 1

私は私の頭の上から、ここですべての詳細を持っていませんが、SPAのと連動するように設定IdentityServer4プロジェクトを見てきました。

documentationのこの作品をチェックしてください：ユーザー 認証のために、ブラウザベースのJavaScriptクライアント（例えばSPA）を定義

をし、このクライアントは、識別情報を要求するために、暗黙の流れを呼ばれるので を使用してアクセスし、APIを委任そして JavaScriptからアクセストークン：

var jsClient = new Client { 
ClientId = "js", 
ClientName = "JavaScript Client", 
ClientUri = "http://identityserver.io", 

AllowedGrantTypes = GrantTypes.Implicit, 
AllowAccessTokensViaBrowser = true, 

RedirectUris =   { "http://localhost:7017/index.html" }, 
PostLogoutRedirectUris = { "http://localhost:7017/index.html" }, 
AllowedCorsOrigins =  { "http://localhost:7017" }, 

AllowedScopes = 
{ 
    IdentityServerConstants.StandardScopes.OpenId, 
    IdentityServerConstants.StandardScopes.Profile, 
    IdentityServerConstants.StandardScopes.Email, 

    "api1", "api2.read_only" 
} }; 

あなたは、すべてのリダイレクトが同じURLに戻って見ることができます。おそらく、あなたのルーティングはそこから引き継ぐでしょう。

Answer 2

UXの質問は多くのことに依存し、セキュリティ上の考慮事項によってUXを調整する必要があります。

クライアントとIDサーバーを完全に所有している場合は、ResourceOwnerPasswordFlowを使用してリダイレクトを行わず、クライアントがユーザー名とパスワードを取得してアクセストークンを取得できるようにすることができます。

この種類のフローは、クライアントを所有していない場合や、資格情報を信頼しない場合はお勧めできません。ウェブサイトがGoogle/Facebookのようなものにログインプロセスを委任する状況を想像してみてください。あなたのID番号（）が本当にのアイデンティティ（Google/Facebook）の所有者である場合、顧客はいくつかのランダムなウェブサイトにパスワードを入力したくありません。その代わりに、リダイレクトフローを使用して、顧客が詳細を入力するのが喜ばれる親しみで信頼できるURLを提示します。

リダイレクトの問題は、セキュリティが強化されている場合、多くの場合、リダイレクトを伴うより良いUXなので、「悪いUXを与えます」という単純な問題ではありません。