OAuth 1.0の具体的なセキュリティ上の欠陥は何でしたか？2.0ではどのように対処されていますか？
私は 記事 を読んで、Twitterを突然引っ張ってOAuthサポートを2009年4月に引き戻した。エンジニアリング」が関わっています。
悪意のあるサイトがOAuthを使用しているふりをして、ユーザー名とパスワードを取得するためにTwitterを模倣することを目的としたフィッシングサイトにユーザーをリダイレクトする可能性があるというのが穴だと思います。これは正しいです？
さらに、欠陥が何であれ、2.0ではどのように対処されていますか？
2009年4月の「セッション固定攻撃」については、ここで説明します。 http://oauth.net/advisories/2009-1/ ここで詳しく説明します： http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack /
セキュリティは、さまざまな視点からのさまざまなことを意味します。このサイトで繰り返し説明しますが、それはすべて脅威モデルに依存します。アプリケーションプロバイダーの脅威モデルはユーザーとは異なり、RIAAとは異なります。
一部のOAuth 2.0ユーザーの間で、暗号署名から「ラップ」モデル：「TLSでラップされたベアラートークン」（Cookieなど）への動きがあります。仕様の編集者は、相互運用可能な検出シナリオの場合： http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ ドラフト11のOAuth 2.0仕様署名のオプションが復活しました。無記名トークンの仕様はコンパニオン仕様に移行しました。また、SAMLとKerberosを介した署名のコンパニオン仕様もあります。おそらく他にもあります。 （OAuth 1.0スキームのように？） http://www.ietf.org/mail-archive/web/oauth/current/msg04573.html
以前の別のコメントも参照してください： http://benlog.com/articles/2009/12/22/its-a-wrap/
ここでは、さまざまなセキュリティの観点に対処するのがいかに面倒になるかについての別の議論があります。
http://benlog.com/articles/2010/09/02/an-unwarranted-bashing-of-twitters-oauth/