OAuth2スコープの明確化が必要

Question

私はIdentityServer3を使用していますが、その問題が存在するのかOAuth2が一般的かそれとも私が理解しているのかは分かりません。 （IdSvrそれを呼び出すことができます）私はアイデンティティサーバが持っているので、アプリケーションのスイート全体でのシングルサインオンを手配したい

とクライアントアプリケーションのカップルが（呼び出しをすることができます：ここで

tl:dr 

How do I allow my user to have different claims in each app using single-sign-on? 

シナリオですそれらのAppAとAppB）。

AppAは、ユーザーのプロファイル情報、電子メール情報、およびいくつかのAppA固有のデータを知る必要があります。 AppBは、ユーザーのプロファイル情報、電子メール情報、およびAppB固有のデータを知る必要があります。これをサポートするために、スコープ「ScopeA」はクレーム「A01」、「A02」などをカバーし、スコープ「ScopeB」はクレーム「B52」、「B53」などをカバーしています。

今AppAのが私のユーザーを認証する必要があるとき、それは「OpenIDのプロファイルの電子メールScopeA」を求めIdSvrに要求を行い、「A01」を含む必要な主張を、取得するトークンを取り戻す、「A02」など

私のユーザーがAppBに行くと、彼は認証されていると判断して、すでに取得したクレームを取得します。 AppAが認証を開始したときにScopeBを要求しなかったので、「B01」、「B02」などはありません。

この場合、ScopeBクレームを取得するには、私はユーザーに署名し、ScopeBを含む新しい認証を要求する必要があります。

私のユーザーがAppAに戻ってきた場合、ScopeAのクレームは、彼がまだ認証されていても失われています。

私はスコープ機能を使用して、クレームを分けてAppB固有のクレームがAppAの使用を妨げないようにすることを期待していました。私はまた、既存の認証にそれが含まれていない場合、AppBがScopeBを求める独自の要求をすることができると予想した。

私は誤解しましたか？最初の認証ですべてのユーザーのクレームにアクセスできるトークンを取得し、各消費者アプリに、それが必要でない、または秘密にしてはいけないものをフィルタリングする責任を負うようにしますか？スコープのポイントは何でしょうか？

Answer 1

アイデンティティ・サーバーにはCookieが格納されているため、将来のリクエストですでに認証されています。ログイン画面ではなく、同意画面が表示されます（同意が必要な場合）。スコープ/クライアントに基づいて、クレームとトークンが生成されます。 AppBの新しいトークンを取得するためにログアウトする必要はありません。

IdentityServerがクライアントにリダイレクトされると、クエリ文字列を介してトークンが渡されます。そのトークンをどのように保存するかは、あなた次第です。

トークンをキャッシュするためのいくつかの選択肢は、クッキーまたはローカルストレージです。ただし、両方のアプリケーションが同じドメイン上にあり、トークンのキャッシュ/取得に同じキーを使用している場合は、AppAによってキャッシュされたトークンを取り戻すか、AppBのトークンを取得するとAppAトークンを上書きできます。