spring boot oauth2.0とspring security：facebookやslackでユーザのログインに権限（権限）を与える方法

Question

私は、springブートoauth2.0を使って認証サーバーを構築し、david_syerモデルに従います。 GoogleのようなサードパーティのOAuthのプロバイダを経由して

1. レッツユーザーログインするか、ユーザーがユーザー名とパスワードを使用して当社のサーバー上の自分のアカウントを作成し、トークンを生成しましょう -

   私の認証サーバは、次のようありません。

2. ユーザーが外部のoauthのようにログインすると、トークンを保存してリソースAPIサーバーにアクセスするためのUIアプリケーションに同じ（google）トークンを渡すだけです。私は、トークンを確認し、APIアクセスを許可する認証フィルターを持っています。

3. ユーザーがユーザー名とパスワードを使用してトークンを取得すると、ユーザーとそのアクセス許可が格納され、彼のトークンが生成されます。現在のところ、UIは認証サーバーによって生成されたトークンを使用してリソースAPIサーバーにアクセスします。

は今、私の質問は

1. が、これは外部APIからのトークンを使用して、当社のリソースAPIサーバーにアクセスするためにそれを使用する正しい方法はありますか？
2. また、サードパーティのoauthプロバイダを使用してサインアップしているユーザに、ユーザエントリと権限を追加しないために権限を追加するにはどうすればよいですか？

ユーザーが永遠のプロバイダから来たのであれば、（UserDetailsS​​erviceからloadUserByUsername（））は、ユーザーとユーザーの権限をロード春のセキュリティは、任意のものを持っていません。

Answer 1

私はステップ2の提案があります： ユーザーがGoogle認証を使用してアプリケーションページにリダイレクトされた後、サーバー上でクレーム変換を行い、所有しているIDサーバーによって発行された独自のトークンを生成します。

理由は特定のクレームを提供することができ、クレーム名は必ずしも一致する必要はありません。

こうすることで、クライアントアプリケーションで自分のトークンを常に確認し続けることができます。したがって、ユーザーがGoogleではなくFacebookを使用し、自分のトークンを割り当てるときにそのシナリオであっても、別の第三者IDサーバーからのトークンを確認する必要はありません。

あなたのIDサーバーはFacebook、Google提供のトークンを信頼し、アプリケーションは自分のIDサーバーだけを信頼するので、IDPがトークンを発行しているかどうかを知る必要はありません。

上記で提案したアプローチでは、ユーザー自身のクレームを変更することもできますし、クレームを提供するために第三者IDサーバーに依存する必要もありません。