oAuth 2.0 を使用して、"authorization-code" Authorization Grant で、最初に "/authorize" を呼び出してコードを取得し、次に "/token" への呼び出し内でこのコードを使用してアクセス トークンを取得します。
私の質問：なぜこれが流れなのですか？セキュリティ上の理由からだと思いますが、わかりません。実装がこのようになっていて、最初の呼び出し (「/authorize」) の直後にアクセス トークンを取得しないのはなぜですか?
なぜこのコードが必要なのですか?
また、この中間ステップを使用することで、クライアントがアクセス トークンを認識できなくなる可能性もありますか?
オライリーの本から：
認証コードこの許可タイプは、サーバー側の Web アプリケーションに最も適しています。リソース所有者がデータへのアクセスを承認すると、URL のクエリ パラメーターとして承認コードを使用して、Web アプリケーションにリダイレクトされます。このコードは、クライアント アプリケーションによってアクセス トークンと交換される必要があります。この交換はサーバー間で行われ、client_id と client_secret の両方が必要なため、リソース所有者でさえアクセス トークンを取得できません。この権限付与タイプでは、更新トークンを使用して、API への長期アクセスも許可されます。
ブラウザーベースのクライアント側アプリケーションの暗黙的な許可 暗黙的な許可は、すべてのフローの中で最も単純であり、ブラウザーで実行されるクライアント側の Web アプリケーション用に最適化されています。リソース所有者がアプリケーションへのアクセスを許可すると、新しいアクセス トークンがすぐに作成され、URL の #hash フラグメントを使用してアプリケーションに返されます。アプリケーションは、(JavaScript を使用して) ハッシュ フラグメントからアクセス トークンをすぐに抽出し、API 要求を行うことができます。この付与タイプは、中間の「承認コード」を必要としませんが、長期アクセス用のリフレッシュ トークンも使用できません。
更新 - はい、確かに：
認証コード フローはいつ使用する必要がありますか? 認証コード フローは、次の場合に使用する必要があります。
長期間のアクセスが必要です。
OAuth クライアントは Web アプリケーション サーバーです。
API 呼び出しの説明責任は非常に重要であり、OAuth トークンは、ユーザーがアクセスできるブラウザーに漏洩してはなりません。
もっと：
おそらく最も重要なのは、アクセス トークンがブラウザー経由で送信されないため、アクセス トークンがブラウザーの履歴、リファラー ヘッダー、JavaScript などを通じて悪意のあるコードに漏洩するリスクが少ないことです。
認証コードフローは、サードパーティが関与するシナリオを対象としています。
これらの当事者は次のとおりです。
クライアント
Web ブラウザを使用するユーザー。彼はあなたのアプリケーションを使用したいと考えています。
プロバイダ
ユーザーに関する情報があります。誰かがこのデータにアクセスしたい場合、ユーザーは最初に同意する必要があります。
あなたの（ウェブ）アプリケーション
プロバイダーからユーザーに関する情報にアクセスしたい。
これで、アプリはユーザー/authorizeに次のように伝えます (ブラウザーをエンドポイントにリダイレクトします)。
ちょっとユーザー、これが私のクライアントIDです。プロバイダーと話して、私と直接話すことを彼に許可してください.
そのため、ユーザーはプロバイダーに話しかけます (承認コードを要求し、ブラウザーでコールバック URL を開いてアプリに返します)。
プロバイダーさん、このアプリを使いたいので、データにアクセスする必要があります。いくつかのコードを教えてください。このコードをアプリケーションに渡します。
これで、アプリにはclient AND providerによって既に知られている認証コードが含まれます。これをプロバイダーに引き渡すことで、アプリは、クライアントが自分のデータへのアクセスを許可されたことを証明できます。プロバイダーが (ウェブ) アプリにアクセス トークンを発行するようになったため、(ウェブ) アプリは毎回 (少なくともしばらくの間) これらの手順をやり直す必要はありません。
アプリがクライアント側で直接実行されている他の種類のアプリケーション (iPhone/Android アプリや Javascript クライアントなど) の場合、中間ステップは不要です。
クライアント側のデータは一般的に安全ではないと考えられています。最初のステップ自体でトークンが付与される暗黙的な呼び出しの場合、access_token を持っている人なら誰でもデータを要求できますが、API は誰がその API を呼び出しているかを知りません。
ただし、アプリケーションが自身を識別したい Web サーバー アプリケーションの場合、client_secret を含む client_id が、access_token を取得するための authentication_code とともに送信されます。これは、将来的には個別に送信できます。
access_token が最初に付与された場合、client_id と access_token は引き続き公開されていると見なされるため、アプリは毎回 access_token に加えて client_secret を送信して、要求が実際にアプリから送信されていることを確認する必要があるとします。
現在のシナリオでは、access_token を取得した後、client_secret を必要とせずに、さらに要求を行うことができます。
1つの重要なポイントは
おそらく最も重要なのは、アクセス トークンがブラウザー経由で送信されることがないため、アクセス トークンがブラウザーの履歴、リファラー ヘッダー、JavaScript などを通じて悪意のあるコードに漏洩するリスクが少ないことです。