web-dev-qa-db-ja.com

spring-security-oauth2 authorizedGrantTypesの構成は実際にはどういう意味ですか？

たとえば、デフォルトのjhipster UAA構成では、次のようになっています。

clients.inMemory() .withClient("web_app") .scopes("openid") .autoApprove(true) .authorizedGrantTypes("implicit","refresh_token", "password", "authorization_code") .and() .withClient(jHipsterProperties.getSecurity() .getClientAuthorization().getClientId()) .secret(jHipsterProperties.getSecurity() .getClientAuthorization().getClientSecret()) .scopes("web-app") .autoApprove(true) .authorizedGrantTypes("client_credentials");

では、「authorizedGrantTypes」は実際には何を意味するのでしょうか。最初のクライアント「web_app」には、リフレッシュを含むさまざまなタイプがあり、2番目のクライアントはclient_credentialsとしてトークンを生成できます。違いはなんですか？

別の質問、「client_credentials」を使用する2番目のクライアント認証の目的は何ですか？これは、保存されている実際のユーザーから切断されているためです。マイクロサービスからマイクロサービスへの通信？ゲートウェイを介した外部認証を許可するように構成が春のクラウド（クライアントおよび秘密のハードコードされた構成）にデプロイされている場合、見栄えが悪いこれを防ぐには？

springspring-bootjhipsterspring-security-oauth2
9
Costa

OAuth 2.付与タイプ は、クライアントアプリケーションがトークンを取得できるさまざまな「方法」です。

articles で説明しています better がたくさんありますが、ここに要約があります：

  • authorization_codeは「クラシック」OAuth 2.0フローであり、ユーザーはリダイレクトを通じて同意を求められます。クライアントアプリケーションは、すべての資格情報（client_id + client_secret + redirect_uri）トークンを取得する前に。
  • implicitは、authorization_codeとほとんど同じですが、パブリッククライアント（Webアプリまたはインストール済み/モバイルアプリ）向けです。フローはユーザーの観点からはほとんど同じですが、より弱いclient認証です。 redirect_uriは、クライアントがリダイレクト+リクエストパラメータを介してアクセストークンを受信するため、唯一のセキュリティです。
  • passwordは簡単です。クライアントアプリケーションはユーザーの資格情報を収集し、ユーザーの資格情報（username + password）と自身の資格情報（client_id + client_secret）トークンと引き換えに。このフローは、承認と認証を組み合わせたものであり、他に選択の余地がない場合にのみ使用する必要があります（つまり、ユーザーがネイティブアプリとブラウザを切り替えないようにする独自のインストール済み/モバイルアプリケーション）。第三者がこのフローを使用することを決して許可しないでください。

これらすべてのフローで、ユーザーは何らかの方法で許可を求められます。クライアントに与えられたトークンは、その単一のユーザーのデータへのアクセスのみを許可します。

client_credentials付与は、ユーザーが関与しないため、異なります。これは、HTTP Basicの代替品です。
リクエストごとにユーザー名（client_id）+パスワード（client_secret）を送信する代わりに、クライアントはトークンと引き換えに認証情報を送信します。

これは、サーバー間の通信で使用されます。ここでは、「どのアプリケーションが呼び出しているか」を明確な資格情報を提供することによって知りたいが、その認証を特定のユーザーに関連付けません。

いくつかの例 ：

  • 保護されたサービスを使用するコマンドラインアプリケーション（バッチ）またはワーカープロセス。この種のアプリケーションは、おそらく多数のユーザーデータを一度に処理し、各ユーザーの同意を要求することはできません。呼び出されるサービスは、クライアントアプリケーションが何かにアクセスできるようにするために、「だれが」呼び出しているのかを知る必要があります。
  • aPIのサードパーティ/外部クライアントが、ユーザーデータにリンクされていない情報（たとえば、使用統計、割り当て、請求など）を知りたい
  • すべてのユーザーのデータにアクセスできる特別な権限を持つサードパーティ/外部クライアント

注：サービス間通信では、各中間アプリケーションに独自のトークンを要求させるのではなく、外部から受信したトークンを中継する必要があります。

19
Michael Técourt