[解決済み] OAuth Authorization CodeとImplicitワークフローの違いは何ですか？それぞれを使用するタイミングは？

質問

OAuth 2.0には複数のワークフローがあります。この2つに関して、いくつか質問があります。

1. 認証コードの流れ - ユーザーがクライアントアプリからログインすると、認証サーバーからアプリに認証コードが返されます。アプリは認証コードをアクセストークンに交換します。
2. 暗黙のグラントフロー - ユーザーがクライアントアプリからログインすると、認可サーバーがクライアントアプリにアクセストークンを直接発行します。

この2つのアプローチは、セキュリティの面でどのような違いがあるのでしょうか？また、どちらがより安全なのでしょうか？

サーバーが直接アクセストークンを発行できるのに、1つのワークフローで余分なステップ（認証コードとトークンの交換）が追加される理由がわからないのですが。

異なるウェブサイトによると、認証コードフローは、クライアントアプリが認証情報を安全に保つことができる場合に使用されるそうです。なぜですか？

解決方法は？

その access_token は、保護されたリソース（API）を呼び出すために必要なものです。Authorization Codeのフローでは、これを取得するために2つのステップがあります。

1. ユーザーが認証し code をAPIコンシューマ（"Client"と呼びます）に送信します。
2. API のクライアント（通常はウェブサーバー）は、この API を使用するために code で取得したデータを access_token で自分自身を認証する。 client_id と client_secret
3. そして、APIを呼び出すには access_token .

つまり、APIを通じて表面化したリソースを所有するユーザーと、APIを利用するクライアント（Webアプリなど）の二重チェックがあるわけだ。どちらもアクセスが許可されるために検証されます。ここでOAuthのquot;authorization"の性質に注目してください：ユーザは自分のリソースへのアクセスを（APIの code 認証後に返される）アプリに、アプリは access_token というように、ユーザーの代わりに呼び出す。

暗黙のフローでは、ステップ2が省略される。そのため、ユーザー認証の後に access_token が直接返され、それを使ってリソースにアクセスすることができます。APIは誰がそのAPIを呼び出しているのか知らない。誰でも access_token ができますが、前の例ではウェブアプリだけがアクセスできます（内部には通常誰もアクセスできません）。

暗黙のフローは、通常、以下のようなシナリオで使用されます。 client id と client secret は推奨されません（例えばデバイス、いずれにせよ多くの人がそうしていますが）。これが免責事項の意味するところです。クライアントコードにアクセスできる人がいるため、認証情報を取得してリソースクライアントのふりをすることができます。暗黙のフローでは、すべてのデータは揮発性であり、アプリには何も保存されません。