私たちのクライアント（モバイルアプリケーション）については、client_id、client_secret、およびユーザーのユーザー名とパスワードを使用してクライアントを認証するパスワード許可タイプを使用できます。OAuth2のパスワード許可タイプ（ROPC）の目的は何ですか？
client_secretを使用しないで、client_secretをユーザ名とパスワードの送信に使用する利点は何ですか？
client_secretを使用して、誰かがAndroidアプリケーションをデコンパイルして、client_secretを取得すると、最初にその利点がありますか？
質問が2つありますので、1つずつ取り上げてください。
OAuth2のパスワード許可タイプ（ROPC）の目的は何ですか？
この助成金型の大きな目的は、彼らに代わって他のリソースにアクセスするための方法として、エンドユーザーのユーザー名とパスワードを格納されたアプリケーションのためのOAuth 2.0へのシームレスな移行を提供することです。ユーザーのパスワードを保存することは大きな問題ではないため、開発者がOAuth 2.0に移行するための良い方法です。
...
client_secretせずにユーザー名とパスワードを送信する上でclient_secretを使用する利点は何ですか？
ユーザ名とパスワードは、エンドユーザを認証する目的で使用されます。つまり、特定のIDを持つユーザーからの要求であることを確認する必要があります。 クライアントシークレットは、同様の目的を持ち、クライアントアプリケーション自体を認証するために使用されます。
既知の信頼できるクライアントから要求が発行されていることを信頼できるという利点があります。複数のクライアントを安全に区別できる場合は、大変便利です。
ネイティブアプリケーションでクライアントシークレットを使用することに関して、誰かが逆コンパイルしてシークレットを取得するだけの場合、このタイプのクライアント認証を信頼できないため、これを考慮する必要はありません。
ただし、OAuth2では、機密クライアントにクライアントシークレットを使用する必要があります。これは、ネイティブアプリケーションがクライアントシークレットを安全に維持できない場合には当てはまりません。この場合、クライアントの資格情報/秘密情報なしにROPCを実行します。
この可能性は、example tutorial from Auth0 about how you can perform a ROPC grant type requestに示されています。次のスニペットでわかるように、非機密クライアントであることを前提にクライアント秘密パラメータを使用しています。
var options = { method: 'POST',
url: 'https://YOUR_AUTH0_DOMAIN/oauth/token',
headers: { 'content-type': 'application/json' },
body:
{ grant_type: 'password',
username: '[email protected]',
password: 'pwd',
audience: 'https://someapi.com/api',
scope: 'read:sample',
client_id: 'XyD....23S' },
json: true };