私はそれについてインターネットでいくつかの情報を探していましたが、Oauth 1.0 プロトコルの RFC にたどり着きました: https://www.rfc-editor.org/rfc/rfc5849
その上部にある「Obsoleted by: 6749」を読むことができます。そのリンクをたどると、OAuth 2.0 Authorization Framework RFC にたどり着きます。
それに基づいて、OAuth 1.0 が廃止され、OAuth 2.0 が優先されたと安全に推測できますか?
ありがとう。
はいといいえ。
IETF は、OAuth 1.x を廃止する新しいバージョンの OAuth 2 を公開しており、新しい認証プロバイダーを OAuth2 に切り替えることを強く推奨しています。
OAuth 1.0a にはリビジョンがあり、1.0 で見つかったセキュリティ上の欠陥の多くが修正されており、これまでで最も安全な OAuth バージョンであると広く考えられています。
OAuth2 はまったく新しいプロトコルであり、OAuth 1.x との下位互換性はありません。OAuth 1 との主な相違点は、このスレッドにリストされています。
ただし、誰もが新しい標準に満足しているわけではありません。OAuth 仕様の筆頭著者であり編集者である Eran Hammer-Lahav は、このブログ投稿で理由を挙げて委員会を辞任しました。
Github でのエクスプロイトで有名になった Homakov は、OAuth 2 についてあまり良いことを言いません。
そうです、OAuth 2 は正式に OAuth 1.x を置き換えましたが、OAuth2 を使用するか、OAuth 1.0a を使用するかについて、ネット上で意見が対立しています。
あなたの質問に対する直接的な答えはyesです。OAuth 2.0仕様から：
新しい実装がこのドキュメントで指定されているように OAuth 2.0 をサポートし、OAuth 1.0 は既存の展開をサポートするためだけに使用されることが、この仕様の意図です。
私は OAuth 2.0 を好み、2.0 承認サーバーを実装して仕様に貢献しましたが、どちらが優れているとは言えません。2.0の方が使いやすいと思います。
有用なプロトコルとして、OAuth 1.0 は時代遅れでも無関係でもありません。バージョン 1.0a (RFC 5849 は 1.0a) の時点で、2.0 よりも安全性が低くなる脆弱性を私は知りません。実際、デフォルトでより安全になっていることは間違いありません。1.0 は、ほとんどのユース ケースを同様に処理できます。
OAuth 2.0 は OAuth 1.0 と互換性がありません。これはまったく新しいプロトコルです。2.0 の開発を推進した設計上の決定は、1.0自体の欠陥に根ざしたものではなく、OAuth を実装しやすくし、1.0 では困難なユースケース (ネイティブなど) をよりエレガントにしたいという願望から 2.0 が生まれました。アプリ）。
注目に値するかもしれないいくつかの違い：
2.0 は、TLS 暗号化接続によって提供されるセキュリティに依存しています。1.0 は TLS を必要としません。その結果、中間者攻撃に対する独自の防御を含める必要があるため、プロトコルはより複雑になります。たとえば、1.0 は保護されたリソースにアクセスするために署名された要求に依存していますが、2.0 ははるかに単純なBearerアクセス トークン タイプを提供します。
2.0 では、OAuth サーバーを(1) 認可サーバーと (2) リソース サーバーの 2 つの概念的な役割に分割します。この関心の分離は、さまざまな種類のリソースを担当する多くのサーバーに承認の懸念が分散している企業に自然に適合します。
2.0 では、機密クライアントとパブリック クライアントが区別されます。パブリック クライアントはユーザー デバイス上で実行されるクライアントであるため、シークレット (ハードコードされた埋め込み資格情報) を確実に保持することはできません。機密クライアントとパブリック クライアントを区別すると、クライアント アプリケーション開発者のニーズに合った安全な実装の決定が容易になります。
2.0 では、複数の承認付与タイプが導入されています。各付与タイプには独自のプロトコル フローがあり、これらのプロトコル フローにより、OAuth 2.0 は複数のユース ケースとクライアント タイプに適応できます。
2.0 では、拡張性を高めるために多大な努力が払われています。仕様のセクション 8では、新しいアクセス トークン タイプ、許可タイプ、およびプロトコル パラメータを定義するための規定を作成しています。たとえば、ベアラー トークンに加えて、MAC トークンとJWT ベアラー トークンに取り組んでいます。
これは主観的なものですが、OAuth 1.0 では開発者がユース ケースをより厳密なフレームワークに適合させる必要があったのに対し、OAuth 2.0 は多くのユース ケースに対して柔軟に対応しようとしていると言う人もいるかもしれません。
OAuth 1.0 が廃止され、OAuth 2.0 が優先されたと言えるとは思えません。1.0 が要求に合っている場合は、引き続き 1.0 を使用できます。
2.0 は、Twitter が廃止を行い、API を 1 から 1.1 に変更したように、大規模な場合に適しています。新しい OAuth を利用するためですが、それは twitter に関係しています。別のケースでは 1.0 かもしれません。まだ完全に機能しているため、アップグレードする必要はありません。
OAuth 2.0。公開暗号化、公開鍵と同様に行う必要があります。そして、その方法は何年も前から知られているので、非公開ではなく、素晴らしいニュースではありません. そのため、良いか悪いかについては、まださまざまな意見があります。
ここでは Oauth2.0 と the road to hell、ここではOAuth 2.0'bad'を参照すると、より興味深く詳細な情報が得られると思います。