「暗黙的」フローでは、リソース所有者 (つまりユーザー) がアクセスを許可した後、クライアント (おそらくブラウザー) はアクセス トークンを取得します。
ただし、「認証コード」フローでは、クライアント (通常は Web サーバー) は、リソース所有者 (つまりユーザー) がアクセスを許可した後にのみ認証コードを取得します。次に、その認証コードを使用して、クライアントは API への別の呼び出しを行い、client_id と client_secret を認証コードと共に渡し、アクセス トークンを取得します。すべてがここでよく説明されています。
どちらのフローも、アクセス トークンというまったく同じ結果になります。ただし、「暗黙的」フローははるかに単純です。
質問: 「暗黙の」フローの継ぎ目は問題ないのに、なぜ「認証コード」のフローに煩わされるのですか? Webサーバーにも「暗黙的」を使用しないのはなぜですか?
プロバイダーとクライアントの両方にとってより多くの作業です。
tl; dr：これはすべてセキュリティ上の理由によるものです。
OAuth 2.0は、次の2つの基準を満たすことを望んでいました。
以下の詳細：
暗黙的なフローは、セキュリティ上の理由から、ブラウザ環境でのみ可能です。
暗黙的なフローでは、アクセストークンは（URLパラメーターとしてではなく）ハッシュフラグメントとして直接渡されます。ハッシュフラグメントに関する重要なことの1つは、ハッシュフラグメントを含むリンクをたどると、ブラウザだけがハッシュフラグメントを認識することです。ブラウザは、ハッシュフラグメントを宛先Webページ（リダイレクトURI /クライアントのWebページ）に直接渡します。ハッシュフラグメントには、次のプロパティがあります。
これにより、仲介サーバーによって傍受されるリスクなしに、アクセストークンをクライアントに直接渡すことができます。これには、クライアント側でのみ可能であるという警告があり、アクセストークンを使用するにはクライアント側でJavaScriptを実行する必要があります。
暗黙的なフローにはセキュリティの問題もあり、たとえば次のような回避策/回避策を追加する必要があります。
承認コードフローでは、URLパラメータがHTTPリクエストの一部であるため、URLパラメータでアクセストークンを直接渡すことはできません。したがって、リクエストが通過する中間サーバー/ルーター（数百になる可能性があります）は、中間者攻撃と呼ばれる攻撃を許可する暗号化接続（HTTPS）を使用していない場合は、アクセストークンを読み取ります。
理論的には、アクセストークンをURLパラメータで直接渡すことは可能ですが、認証サーバーは、リダイレクトURIがTLS暗号化と「信頼できる」SSL証明書（通常は無料ではない認証局から）を使用するHTTPSを使用していることを確認する必要があります。宛先サーバーが正当であり、HTTP要求が完全に暗号化されていることを確認します。すべての開発者にSSL証明書を購入させ、ドメインでSSLを適切に構成させることは大きな苦痛であり、採用を大幅に遅らせることになります。これが、正当な受信者のみが交換できる（クライアントシークレットが必要なため）中間の1回限りの「認証コード」が提供され、暗号化されていないトランザクションでリクエストを傍受する潜在的なハッカーにはコードが役に立たない理由です。 （彼らはしないので
また、暗黙のフローの安全性が低く、リダイレクト時にドメインをスプーフィングするなどの潜在的な攻撃ベクトルがあると主張することもできます。たとえば、クライアントのWebサイトのIPアドレスを乗っ取るなどです。これが、暗黙的なフローがアクセストークン（使用時間が制限されていると想定される）のみを許可し、トークン（時間に制限がない）を更新しない理由の1つです。この問題を解決するには、可能な限りHTTPS対応サーバーでWebページをホストすることをお勧めします。
OAuth仕様から：
4.2. 暗黙の付与
暗黙的な付与タイプは、アクセス トークンを取得するために使用され (更新トークンの発行はサポートされません)、特定のリダイレクト URI を操作することがわかっているパブリック クライアント用に最適化されています。これらのクライアントは通常、JavaScript などのスクリプト言語を使用してブラウザーに実装されます。
これはリダイレクトベースのフローであるため、クライアントはリソース所有者のユーザー エージェント (通常は Web ブラウザー) と対話でき、承認サーバーから (リダイレクト経由で) 着信要求を受信できる必要があります。
クライアントが承認とアクセス トークンを個別に要求する承認コード グラント タイプとは異なり、クライアントは承認要求の結果としてアクセス トークンを受け取ります。
暗黙的な付与タイプにはクライアント認証が含まれず、リソース所有者の存在とリダイレクト URI の登録に依存します。アクセス トークンはリダイレクト URI にエンコードされるため、リソース所有者や同じデバイスに存在する他のアプリケーションに公開される可能性があります。
したがって、次のことが考えられます。
これはパブリック OAuth 用です。つまり、クライアントを登録する必要がなく、独自のクライアント シークレットを持っていない場合です。しかし、どの認証サーバーがリダイレクト URL をチェックするか、これは実際にはセキュリティ上十分です。
アクセス トークンはブラウザのアドレス バーに表示されるため、ユーザーは URL をコピーして他のユーザーに送信できます。また、ユーザーとしてログに記録されます。つまり、セッション固定のようなものです。ただし、ブラウザーは履歴を置き換えて追加のリダイレクトを行い、URL からハッシュ フラグメントを削除します。ハッカーが HTTP トラフィックを傍受してアクセス トークンを盗むことも可能ですが、これは HTTPS で簡単に保護できます。悪意のあるブラウザー拡張機能の中には、アドレス バーから URL にアクセスできるものがありますが、これは HTTPS 証明書の破損など、最終的には悪い状況です。そして、Auth コード フローでさえ、ここでは役に立ちません。したがって、URLのハッシュフラグメントを介してアクセストークンを渡すことは絶対に安全であることがわかります。
エフェメラル アクセス トークンとリフレッシュ トークンの分離は、HTTPS を使用する場合には役に立たず、生の HTTP でも正直言ってあまり役に立ちません。しかし、暗黙的なフローを介したクライアントが更新トークンを受信できないという事実もナンセンスです。
したがって、https で厳密に機能し、リフレッシュ トークンを許可し (またはトークンをまったく削除する必要があります)、Auth Cose グラント フローよりも望ましい、新しいグラント フロー「安全な暗黙的」を導入する必要があると思います。
「暗黙的」フローでは、クライアント (おそらくブラウザー) は、ブラウザーのリダイレクト (GET 操作) を介してアクセス トークンを取得します。ブラウザ ベースの通信は安全ではなく、クライアント シークレットまたはトークンが傍受または盗まれる可能性があります。
「認証コード」フローでは、クライアント (通常は Web サーバー) は、ブラウザーのリダイレクト (GET 操作) を介して認証コードのみを取得します。次に、サーバーは、承認サーバーに対して (ブラウザー以外の) POST 呼び出しを行うことにより、このコードをトークンと交換します。サーバーには、トークン アクセス呼び出し用のクライアント シークレットのみが含まれます。
注 - oauth のベスト プラクティスによると、「クライアントは、暗黙的な付与 (応答タイプ「トークン」) または認証応答でアクセス トークンを発行する他の応答タイプを使用すべきではありません」。
お役に立てれば。