OAuth 2はOAuth 1とどう違うのですか？
非常に簡単に言えば、誰かがOAuth 2とOAuth 1の違いを説明できますか？
OAuth 1はもう時代遅れですか？ OAuth 2を実装する必要がありますか？ OAuth 2の実装はあまり多くありません。ほとんどの人はまだOAuth 1を使用しているので、OAuth 2を使用する準備ができていることには疑問があります。それは...ですか？
Eran Hammer-Lahavは、彼の記事 OAuth 2.0の紹介 の違いの大部分を説明するのに優れた仕事をしました。まとめると、主な違いは次のとおりです。
ブラウザベースではないアプリケーションに対するサポートを向上させるためのOAuthフローが増えました。 これはブラウザベースではなかったクライアントアプリケーションからのOAuthに対する主な批判です。たとえば、OAuth 1.0では、デスクトップアプリケーションまたは携帯電話アプリケーションは、ブラウザを開いて目的のサービスにアクセスし、サービスで認証し、サービスからアプリケーションにトークンをコピーし直すようにユーザーに指示する必要がありました。ここでの主な批判は、ユーザーエクスペリエンスに対するものです。 OAuth 2.0では、アプリケーションがユーザーの承認を得るための新しい方法があります。
OAuth 2.0では、クライアントアプリケーションに暗号化機能が不要になりました。 これは、HMACハッシュトークンと要求文字列へのアプリケーションを必要としなかった古いTwitter認証APIに話を戻します。 OAuth 2.0では、アプリケーションはHTTPS経由で発行されたトークンのみを使用してリクエストを行うことができます。
OAuth 2.0の署名はそれほど複雑ではありません。 これ以上の特別な構文解析、ソート、またはエンコードは不要です。
OAuth 2.0アクセストークンは「短命」です。 通常、OAuth 1.0アクセストークンは1年以上保存できます（Twitterでは期限切れにすることはできません）。 OAuth 2.0にはリフレッシュトークンの概念があります。これらが何であるか完全にはわかりませんが、あなたのアクセストークンは短期間（すなわちセッションベース）にすることができますが、あなたのリフレッシュトークンは「寿命」にすることができます。ユーザーにアプリケーションの再承認を依頼するのではなく、更新トークンを使用して新しいアクセストークンを取得します。
最後に、OAuth 2.0では、OAuth要求の処理を担当するサーバーとユーザー認証の処理を担当するサーバーとの間で、役割が明確に分離されています。 それについてのさらなる情報は前述の記事で詳述されています。
私はここで素晴らしい答えを見ますが、私が見逃したのはいくつかのダイアグラムでした、そして私が出会ったのはSpring Frameworkで作業しなければならなかったので 彼らの説明 。
私は以下の図がとても役に立つと思います。彼らは、OAuth2とOAuth1の当事者間のコミュニケーションの違いを説明しています。
OAuth 2
OAuth 1
これまでの説明はすべて、過度に詳細で複雑なIMOです。簡単に言うと、OAuth 2はHTTPSプロトコルにセキュリティを委任します。 OAuth 1はこれを必要とせず、結果としてさまざまな攻撃に対処するための代替方法を持っていました。これらの方法では、アプリケーションが複雑で実装が難しい可能性がある特定のセキュリティプロトコルを使用する必要がありました。そのため、アプリケーション開発者が心配する必要がないように、セキュリティに関してはHTTPSに頼るほうが簡単です。
あなたの他の質問に関しては、答えは異なります。 HTTPSの使用を必要としないサービス、OAuth 2より前に開発されたサービス、またはOAuth 2の使用を妨げるその他の要件があるサービスもあります。さらに、OAuth 2プロトコル自体について多くの議論がありました。ご覧のとおり、Facebook、Google、およびその他のいくつかのプラットフォームでは、それぞれプロトコルのバージョンが多少異なります。そのため、OAuth 1が異なるプラットフォーム間で統一されているため、OAuth 1を使用する人もいます。最近、OAuth 2プロトコルが完成しましたが、その採用がどうなるかはまだわかりません。
Oauth 2を使用することに対する重大なセキュリティ上の議論があります。
これらはOauth 2の主執筆者によるものです。
キーポイント：
Oauth 2はSSLに加えてセキュリティを提供しませんが、Oauth 1はトランスポートに依存しません。
ある意味で、SSLはサーバーが接続を検証しないという点で安全ではなく、共通のクライアントライブラリは失敗を無視することを容易にします。
SSL/TLSの問題は、クライアント側で証明書を確認できなかった場合でも、接続が機能することです。エラーを無視して成功することにはいつでも、開発者はまさにそれをするつもりです。サーバーに証明書の検証を強制する方法はありません。たとえ可能であったとしても、攻撃者は確実にそうしないでしょう。
あなたはあなたのセキュリティのすべてを人差し指で片付けることができます、それはOAuth 1.0でするのがはるかに難しいです：
2番目によくある潜在的な問題はタイプミスです。 1文字（「https」の「s」）を省略するとトークンのセキュリティ全体が無効になる場合、それを適切な設計と見なしますか？または、おそらく（有効で検証済みのSSL/TLS接続を介して）間違った送信先にリクエストを送信します（「 http://gacebook.com 」など）。覚えておいて、コマンドラインからOAuthベアラトークンを使用できることは明らかにユースケースベアラトークンの支持者が推進していたことです。
OAuth 1.0プロトコル（ RFC 5849 ）のセキュリティは、クライアントアプリケーションに埋め込まれた秘密鍵を秘密にしておくことができるという仮定に依存しています。しかし、その仮定は素朴です。
OAuth 2.0（ RFC 6749 ）では、そのような単純なクライアントアプリケーションを機密クライアントと呼びます。一方、秘密鍵を秘密にしておくことが難しい環境にあるクライアントアプリケーションは、publicクライアントと呼ばれます。 2.1を参照してください。詳細はクライアントタイプ をご覧ください。
その意味で、OAuth 1.0は機密クライアント専用の仕様です。
「 OAuth 2.0と地獄への道 」は、OAuth 2.0は安全性が低いと述べていますが、OAuth 1.0クライアントとOAuth 2.0機密クライアントの間でセキュリティレベルに実質的な違いはありません。 OAuth 1.0では署名を計算する必要がありますが、クライアント側の秘密鍵が機密に保たれることがすでに保証されている場合はセキュリティが強化されません。シグネチャの計算は、実用的なセキュリティ強化を行わない単なる面倒な計算です。つまり、OAuth 2.0クライアントがTLSを介してサーバーに接続してclient_idとclient_secretを提示するだけの単純さと比較すると、面倒な計算の方がセキュリティの面で優れているとは言えません。
さらに、RFC 5849（OAuth 1.0）では open redirectors について何も言及されていませんが、RFC 6749（OAuth 2.0）では言及されていません。つまり、OAuth 1.0のoauth_callbackパラメータがセキュリティホールになる可能性があります。
したがって、OAuth 1.0がOAuth 2.0よりも安全であるとは思いません。
[2016年4月14日]私の主張を明確にするための追加
OAuth 1.0セキュリティは署名計算に依存しています。秘密鍵がHMAC-SHA1の共有鍵（ RFC 5849、3.4.2 ）またはRSA-SHA1の秘密鍵（ RFC 5849、3.4.3 ）である場合、署名は秘密鍵を使用して計算されます。 ]）。秘密鍵を知っている人なら誰でも署名を計算できます。したがって、秘密鍵が危険にさらされた場合、署名計算の複雑さは無意味ですが複雑です。
これは、OAuth 1.0セキュリティが、署名計算の複雑さと論理ではなく、単に秘密鍵の機密性に依存していることを意味します。言い換えれば、OAuth 1.0セキュリティに必要なのは、秘密鍵を秘密にしておくことができるという条件だけです。これは極端に聞こえるかもしれませんが、条件がすでに満たされている場合、シグネチャ計算はセキュリティ強化を追加しません。
同様に、OAuth 2.0 confidential クライアントも同じ条件に依存します。条件がすでに満たされている場合、TLSを使用してセキュア接続を作成し、そのセキュア接続を介してclient_idおよびclient_secretを許可サーバーに送信することに問題はありますか？ OAuth 1.0機密クライアントとOAuth 2.0機密クライアントの両方が同じ条件に依存している場合、セキュリティレベルに大きな違いはありますか？
OAuth 1.0がOAuth 2.0のせいであるという正当な理由は見つかりません。実際のところ、（1）OAuth 1.0は機密クライアント専用の仕様であり、（2）OAuth 2.0は機密クライアント用のプロトコルを単純化し、 public clientsもサポートしています。よく知られているかどうかにかかわらず、スマートフォンアプリケーションはパブリッククライアントとして分類され（ RFC 6749、9 ）、これはOAuth 2.0の恩恵を受けます。
OAuth 2は明らかに時間の浪費です（それに深く関わっていた誰かの口から）。
https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529
彼は言います（簡潔にするために編集し、強調するために太字にしました）。
...私はもはやOAuth 2.0規格に関連付けることができません。私は主執筆者および編集者としての私の役割を辞任し、仕様から私の名前を撤回し、そしてワーキンググループを辞めました。私が3年間そして20ダースを超える草稿を作成するのに苦労してきた文書から私の名前を削除することは容易ではありませんでした。私が5年以上かけて導いてきた取り組みから先に進むことを決心するのは苦痛でした。
...最後に、私はOAuth 2.0が悪いプロトコルであるという結論に達しました。 WS- *悪い。私はもはやそれに関連付けられたくないということは十分に悪いです。 ... OAuth 1.0と比べると、2.0仕様はより複雑で、相互運用性が低く、有用性が低く、より不完全で、そして最も重要なことは安全性が低くなっています。
はっきりさせるために、 Webセキュリティを深く理解している開発者の手に渡るOAuth 2.0はおそらく安全な実装になるでしょう。しかし、過去2年間の経験のように、ほとんどの開発者の手に委ねられますが、2.0は安全でない実装を生み出す可能性があります。
トークンが生成されると、OAuth 2.0シグネチャは実際のAPI呼び出しには必要ありません。セキュリティトークンは1つだけです。
OAuth 1.0では、クライアントはAPI呼び出しごとに2つのセキュリティトークンを送信し、両方を使用して署名を生成する必要があります。要求を検証するには、保護されたリソースのエンドポイントがクライアントの資格情報にアクセスできる必要があります。
ここ には、OAuth 1.0と2.0の違い、およびその両方の動作についての説明があります。
OAuth 2.0は次のようにして事を単純化することを約束します：
- トークンの生成に必要なすべての通信にSSLが必要です。これらの複雑な署名は必要なくなったので、これは複雑さの大幅な減少です。
- トークンが生成されたら、実際のAPI呼び出しに署名は必要ありません。ここではSSLも強くお勧めします。
- トークンが生成されると、OAuth 1.0では、クライアントはAPI呼び出しごとに2つのセキュリティトークンを送信し、両方を使用して署名を生成する必要がありました。 OAuth 2.0にはセキュリティトークンが1つしかなく、署名は不要です。
- プロトコルのどの部分が「リソース所有者」、つまりAPIを実装する実際のサーバー、およびどの部分が別の「承認サーバー」によって実装されるかによって明確に指定されます。これにより、Apigeeのような製品が既存のAPIにOAuth 2.0サポートを提供することが容易になります。
高度な説明が必要な場合は、両方の仕様を読む必要があります。
フローの違いについて明確な説明が必要な場合は、これが役立ちます。
OAuth 1.0フロー
- クライアントアプリケーションはTwitterなどのプロバイダに登録します。
- Twitterは、そのアプリケーションに固有の「消費者秘密」をクライアントに提供します。
- クライアントアプリサイン TwitterへのすべてのOAuthリクエストwithそのユニークな“消費者の秘密”
- OAuthリクエストのいずれかが不正な形式である、データがない、または不適切に署名されている場合、そのリクエストは拒否されます。
OAuth 2.0フロー
- クライアントアプリケーションはTwitterなどのプロバイダに登録します。
- Twitterは、そのアプリケーションに固有の「クライアントシークレット」をクライアントに提供します。
- クライアントアプリケーションincludes“クライアントシークレット” with every requestは通常、httpヘッダーとして要求されます。
- OAuthリクエストのいずれかが不正な形式、データの欠落、または誤ったシークレットを含む場合、リクエストは拒否されます。
セキュリティの観点から、私はOAuth 1に行きます。 OAuth 2.0と地獄への道
そのリンクからの引用：「あなたが現在1.0をうまく使っているなら、2.0を無視しなさい。それは1.0以上の本当の価値を提供しない（私はあなたのクライアント開発者がすでに1.0署名を考え出していると思う）。
あなたがこの分野に慣れておらず、自分自身をセキュリティの専門家であると考えるならば、その機能を注意深く調べた後に2.0を使ってください。あなたがエキスパートではない場合は、1.0を使用するか、信頼できるプロバイダの2.0実装をコピーして正しく取得してください（FacebookのAPIドキュメントを読むのに適した場所です）。大規模には2.0が優れていますが、大規模な運用を行っている場合は、セキュリティの専門家が現場にいて、それをすべて把握することができるでしょう。」