[解決済み】OAuth 2の暗黙のグラント承認タイプの目的は何ですか？

質問

私の盲点なのか何なのかわかりませんが、OAuth 2 仕様書を何度も読み返し、メーリングリストのアーカイブも熟読しましたが、なぜアクセストークンを取得するための Implicit Grant フローが開発されたのか、まだ良い説明を見つけられずにいます。Authorization Code Grant と比較すると、あまり説得力のない理由でクライアント認証を諦めているように見えます。スクリプト言語を使ってブラウザで実装されたクライアントに最適化されている（仕様書を引用）のはなぜでしょうか？

どちらのフローも出だしは同じです（ソースはこちら。 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22 ):

1. クライアントは、リソース所有者のユーザーエージェントを認可エンドポイントに誘導することで、フローを開始する。
2. 認可サーバーは、（ユーザーエージェントを介して）リソース所有者を認証し、リソース所有者がクライアントのアクセス要求を許可するか拒否するかを確立します。
3. リソース所有者がアクセスを許可したと仮定すると、認可サーバーは、先に（リクエスト内またはクライアント登録時に）提供されたリダイレクトURIを使用して、ユーザーエージェントをクライアントにリダイレクトします。

• リダイレクトURIに認証コードが含まれている（認証コードフロー）
• リダイレクトURIがURIフラグメントにアクセストークンを含む（暗黙のフロー）

ここでフローが分かれる。どちらの場合も、この時点でのリダイレクトURIは、クライアントがホストしている何らかのエンドポイントへのものです。

• 認可コードフローでは、ユーザーエージェントがURIの認可コードでエンドポイントをヒットすると、そのエンドポイントのコードは認可コードをクライアント認証情報と一緒にアクセストークンに交換し、必要に応じて使用することができます。例えば、そのアクセストークンをウェブページに書き込んで、ページ上のスクリプトがアクセスできるようにすることができます。
• Implicitフローでは、このクライアント認証のステップを完全にスキップして、クライアントスクリプトを含むウェブページをロードするだけです。URL の断片を使ったかわいいトリックがあり、アクセストークンがあまり回されないようになっていますが、最終的な結果は基本的に同じです。
  
  

そこで質問ですが、クライアント認証のステップをスキップすることで何が得られるのでしょうか？

解決方法は？

以下は私の考えです。

認証コードとトークンを認可コードフローに含める目的は、トークンとクライアントシークレットがサーバー間で移動するため、リソース所有者に公開されることがないためです。

一方、暗黙の許可フローは、リソース所有者のブラウザで実行される、完全にjavascriptを使用して実装されたクライアントのためのものです。このフローを使用するために、サーバーサイドのコードは必要ありません。なぜなら、トークンやクライアントシークレットは、リソースオーナーと共有されるからです。なぜなら、トークンやクライアントシークレットは依然としてリソース所有者と共有されるからです。認証コードやクライアントシークレットを含めることは、実際のセキュリティを追加することなく、フローをより複雑にするだけです。

つまり、「何が得られたか」という問いに対する答えは、「シンプルであること」なのです。