OAuth Authorization CodeとImplicitワークフローの違いは何ですか？それぞれをいつ使用するか？
OAuth 2.0には複数のワークフローがあります。 2つに関していくつか質問があります。
- 認証コードフロー-ユーザーはクライアントアプリからログインし、認証サーバーは認証コードをアプリに返します。次に、アプリはアクセストークンの認証コードを交換します。
- 暗黙的な許可フロー-ユーザーはクライアントアプリからログインし、承認サーバーはクライアントアプリにアクセストークンを直接発行します。
セキュリティの観点から2つのアプローチの違いは何ですか？どちらがより安全で、なぜですか？
サーバーがアクセストークンを直接発行できる場合、1つのワークフローに余分な手順（トークンの認証コードを交換する）が追加される理由はわかりません。
さまざまなWebサイトは、クライアントアプリが資格情報を安全に保持できる場合に承認コードフローが使用されると述べています。どうして？
access_tokenは、保護されたリソース（API）を呼び出すために必要なものです。承認コードフローには、取得するための2つのステップがあります。
- ユーザーは認証し、
codeをAPIコンシューマー（「クライアント」と呼ばれる）に返す必要があります。 - APIの「クライアント」（通常はWebサーバー）は、＃1で取得した
codeをaccess_tokenと交換し、client_idおよびclient_secretで認証します。 - その後、
access_tokenを使用してAPIを呼び出すことができます。
そのため、二重チェックがあります：APIを通じて表示されるリソースを所有するユーザーと、APIを使用するクライアント（Webアプリなど）です。両方とも、アクセスが許可されるために検証されます。ここでOAuthの「承認」の性質に注意してください。ユーザーは、（認証後に返されるcodeを介して）自分のリソースへのアクセスをアプリに許可し、アプリはaccess_tokenを取得し、呼び出しますユーザーに代わって。
暗黙のフローでは、ステップ2は省略されます。そのため、ユーザー認証後、access_tokenが直接返され、これを使用してリソースにアクセスできます。 APIは、だれがそのAPIを呼び出しているかを知りません。 access_tokenを持っている人は誰でもできますが、前の例ではWebアプリのみができます（通常、内部には誰もアクセスできません）。
通常、暗黙フローは、client idおよびclient secretの保存が推奨されないシナリオで使用されます（たとえば、多くの場合、デバイスはそうしますが）。それが免責事項の意味です。ユーザーはクライアントコードにアクセスできるため、資格情報を取得し、リソースクライアントになるふりをすることができます。暗黙のフローでは、すべてのデータは揮発性であり、アプリには何も保存されません。
上記の回答で明らかにされていないと思うものをここに追加します：
- Authorization-Code-Flowでは、最終access-tokenがブラウザ/アプリでマシンに到達せず、マシンに保存されない。一時的な認証コードはブラウザ/アプリでマシンに与えられ、サーバーに送信されます。サーバーはそれをフルアクセストークンと交換し、APIなどにアクセスできます。ブラウザーを使用するユーザーは、トークンを使用するサーバーを介してのみAPIにアクセスできます。
- 暗黙のフローには2者しか関与できません。最終アクセストークンはブラウザ/アプリとともにクライアントに保存されます。このブラウザ/アプリが危険にさらされると、認証トークンも危険になります。
tl; drトークンを保持するためにユーザーマシンを信頼していないが、do信頼している場合、暗黙のフローを使用しない独自のサーバー。
両者の違いは次のとおりです。
暗黙的なフローでは、トークンは「＃」記号付きのリダイレクトURLを介して直接返され、これは主にJavaScriptクライアントまたは独自のサーバー側を持たないモバイルアプリケーションで使用され、クライアントは一部の実装で秘密を提供する必要はありません。
承認コードフローでは、コードは「？」で返されますサーバー側で読み取り可能にするために、サーバー側は今度はトークンURLにクライアントシークレットを提供して、承認サーバーからjsonオブジェクトとしてトークンを取得する必要があります。これを処理できるアプリケーションサーバーがあり、ユーザートークンを自分のシステムに自分のプロファイルとともに保存する場合に使用され、主に一般的なモバイルアプリケーションに使用されます。
そのため、クライアントアプリケーションの性質に依存します。これは、クライアント上でシークレットをリクエストし、非常にセキュアな接続で認証サーバーとクライアントアプリケーション間でトークンを送信できるため、より安全な「認証コード」一部のクライアントが「認証コード」のみを使用するように制限し、暗黙的を許可しない
暗黙の許可は、2つの明確な違いを除いて、許可コードの許可に似ています。
すべてのアプリケーションコードとストレージに簡単にアクセスできるため、クライアントを秘密にできないユーザーエージェントベースのクライアント（シングルページウェブアプリなど）で使用することを目的としています。
次に、認可サーバーがアクセストークンと交換される認可コードを返す代わりに、認可サーバーがアクセストークンを返します。
詳細はこちらをご覧ください http://oauth2.thephpleague.com/authorization-server/which-grant/
上記の回答から学んだポイントを要約し、私自身の理解の一部を追加しましょう。
認証コードフロー!!!
- OAuthクライアントとして機能するWebアプリケーションサーバーがある場合
- 長期間アクセスしたい場合
- データへのオフラインアクセスが必要な場合
- アプリが行うAPI呼び出しに対して責任がある場合
- OAuthトークンを漏らしたくない場合
- アプリケーションがデータへのアクセスを必要とするたびに認証フローを実行したくない場合。注：Implicit Grantフローは更新トークンを受け入れないため、認証サーバーがアクセストークンを定期的に期限切れにした場合、アプリケーションはアクセスが必要なときはいつでも認証フローを実行する必要があります。
暗黙的な許可フロー!!!
- OAuthクライアントとして機能するWebアプリケーションサーバーがない場合
- 長期間アクセスする必要がない場合、つまりデータへの一時的なアクセスのみが必要です。
- アプリが実行されているブラウザを信頼しており、アクセストークンが信頼されていないユーザーに漏洩する懸念が限られている場合。
暗黙のフロー
長所
- 実装が最も簡単
短所
- ブラウザに表示されるアクセストークン
- アクセストークンの発信元を特定できません
- アクセストークンは期限切れにできません（Googleのポリシーによる）
認証コードフロー
長所
- 最も安全
- アクセストークンと更新トークンは、共有シークレットがわかっている場合にのみ作成できます
- 新しいセキュリティ機能とUX機能が利用可能になったときに、それらを強化できます
短所
- 複数の認証エンドポイントを実装する必要があります
引用： https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows
実用的な観点（私が理解したこと）から、Authzコードフローを持つ主な理由は次のとおりです。
- 更新トークン（ユーザーに代わってアプリによる長期アクセス）のサポート、暗黙的にサポートされていません：参照： https://tools.ietf.org/html/rfc6749#section-4.2
- リソース所有者が提供するアクセスを制御できる場所である同意ページのサポート（Googleに表示される許可の種類/承認ページ）。暗黙的には同じものはありません。セクションを参照してください： https://tools.ietf.org/html/rfc6749#section-4.1 、ポイント（B）
「認可サーバーは（ユーザーエージェントを介して）リソース所有者を認証し、リソース所有者がクライアントのアクセス要求を許可するか拒否するかを確立します。」
それとは別に、更新トークンを使用して、アプリはユーザーデータへの長期アクセスを取得できます。