OAuth 2では、認証コードがあるときにアクセストークンが必要なのはなぜですか？

Question

Appはアクセストークンの認証コードを交換します。そして、アクセストークンのアプリは、API呼び出しを行うことができます。しかし、なぜOAuth 2にこのステップがあるのか​​分かりません。余分なステップのようです。

私が見つけた理由の1つは、クライアント側でリダイレクトコールによって許可コードが与えられていることです。そのため、侵害される可能性があり、短命です。一方、アクセストークンはサーバからサーバに与えられます。

それは本当ですが、Appが送信するSecret Apiキーもあります。なぜ認証コードで同じことをすることができなかったのですか？

アクセストークンはなく、認証のみが存在するとします。次に、認証コードを取得した人でも、Oauth2サーバーが認証コードに沿って秘密鍵をチェックしても、何もできなくなります。

それはのOauthサーバーに許可する必要があります。

1. は、（認可）を直接access_tokenは取得すること

Answer 1

能力を確認要求が付与された権限の種類のアプリ（認証）

によって作られた作ります（暗黙の付与タイプ）は、ブラウザで実行されているJavaScriptクライアントまたはWebアプリケーションの場合に必要です。なぜなら、これらのクライアントは、クライアントシークレットを保存するためのオプションに基づいて安全ではないからです。クライアントIDとシークレットは、access_tokenの認証コードを交換するために必要です。

これら2つの許可タイプは、認証を実装する際にさまざまなレベルのセキュリティを提供するために存在します。

APIによって提供されるリソースが非常に敏感な場合は、認証コードフローによって提供される、ほとんどのセキュリティを必要とします。このグラント・タイプでは、リソースへのアクセスを許可する前に、クライアント（サーバー側APIまたはモバイル・クライアント）とリソース所有者（ユーザー）を検証します。 access_tokenはブラウザー/ユーザーにさらされていません（盗まれたトークンがリソースへのアクセスを与えることができるため）ので、高度なセキュリティが得られます。このフローは複雑で、認証サーバーへのより多くの往復を伴いますが、より多くのセキュリティを提供します。

リソースにこの種のセキュリティが必要ない場合は、ブラウザ/ユーザーがトークンにアクセスできる暗黙の許可タイプを使用できます。このフローは、許可サーバーへの1回のトリップで簡単です。クライアントの検証は行いません。ブラウザでクライアントの秘密を保存する必要はありません。

これはうまくいけばうまくいきます。ご不明な点がございましたらお知らせください。

ありがとう、 Soma。