認証フローのgrant_type = client_credentialsとgrant_type = passwordの違いは？
Authenticationまたはgrant_type=client_credentialsの概念におけるgrant_type=passwordとOAuth2 Flowの違いを理解したいと思います。私は以下のサイトをフォローしています：
JavaScript開発でgrant_type=passwordを使用する限り、not secureの方法でgran_typeを推測します。しかし、私はまだ誰かがこの概念を理解するのを助けることができます。
また、grant_type=client_credentialsは「refresh_token」を提供せず、access_tokenのみを提供しますが、grant_type=passwordはaccess_tokenとrefresh_tokenの両方を提供します。
詳細な説明が欲しい。アプリケーション開発用のOAuth2にWSO2 API Managerを使用しています
リソース所有者の資格情報の付与（パスワード付与タイプ）
この付与が実装されると、クライアント自体がユーザーにユーザー名とパスワードを要求し（認証のためにIdP承認サーバーにリダイレクトされるのではなく）、クライアント自身の資格情報とともにこれらを承認サーバーに送信します。認証が成功すると、クライアントにアクセストークンが発行されます。
この助成金は、サービス自体のモバイルクライアント（SpotifyのiOSアプリなど）などの信頼できるクライアントに適しています。これは、認証コードの実装が簡単ではないソフトウェアでも使用できます。たとえば、この認証付与を OwnCloud にボルトで固定して、LDAP経由でアクセスできなかったユーザーの詳細を取得できるようにしました。大学のActiveDirectoryサーバー。
クライアント資格情報の付与
この付与は、クライアントの資格情報のみがアクセストークンの要求の認証に使用されることを除いて、リソース所有者の資格情報の付与に似ています。この場合も、この付与は信頼できるクライアントのみが使用できるようにする必要があります。
この付与は、マシン間認証に適しています。たとえば、APIを介してメンテナンスタスクを実行するcronジョブで使用する場合などです。もう1つの例は、ユーザーの許可を必要としないAPIにリクエストを送信するクライアントです。
誰かが リンカーン大学のスタッフディレクトリ のスタッフのページのメンバーにアクセスすると、Webサイトは独自のアクセストークン（この助成金を使用して生成された）を使用して、APIサーバーへのリクエストを認証してページの作成に使用されるスタッフのメンバー。ただし、スタッフのメンバーがサインインしてプロファイルを更新すると、独自のアクセストークンを使用してデータを取得および更新します。したがって、関心の分離が適切に行われ、各タイプのアクセストークンが持つアクセス許可を簡単に制限できます。