OAuth 2 と OAuth 1 の違いを説明していただけますか?
OAuth 1 はもう時代遅れですか? OAuth 2 を実装すべきですか? OAuth 2 の実装はあまり見かけません。ほとんどがまだ OAuth 1 を使用しているため、OAuth 2 が使用できる状態にあるかどうか疑問に思います。本当にそうでしょうか?
ベストアンサー1
エラン・ハマー・ラハフは、記事の中で違いの大部分をうまく説明している。OAuth 2.0の紹介。
*編集: 元のリンクは2023年8月13日時点で無効であると報告されました。web.archive.orgからのスナップショットで更新されました
要約すると、主な違いは次のとおりです。
ブラウザベースではないアプリケーションをより適切にサポートできるように、OAuth フローを増やします。これは、ブラウザベースではないクライアント アプリケーションからの OAuth に対する主な批判です。たとえば、OAuth 1.0 では、デスクトップ アプリケーションやモバイル フォン アプリケーションは、ユーザーにブラウザを開いて目的のサービスにアクセスし、そのサービスで認証し、サービスからアプリケーションにトークンをコピーするよう指示する必要がありました。ここでの主な批判は、ユーザー エクスペリエンスに対するものです。OAuth 2.0 では、アプリケーションがユーザーの承認を取得するための新しい方法があります。
OAuth 2.0 では、クライアント アプリケーションに暗号化機能が必要なくなりました。これは、アプリケーションにハッシュ トークンとリクエスト文字列を HMAC する必要がなかった古い Twitter Auth API を思い起こさせます。OAuth 2.0 では、アプリケーションは HTTPS 経由で発行されたトークンのみを使用してリクエストを行うことができます。
OAuth 2.0 署名ははるかにシンプルです。特別な解析、並べ替え、エンコードは不要です。
OAuth 2.0 アクセス トークンは「短命」です。通常、OAuth 1.0 アクセス トークンは 1 年以上保存できます (Twitter ではトークンの有効期限が切れることはありません)。OAuth 2.0 にはリフレッシュ トークンという概念があります。これが何なのかはよくわかりませんが、アクセス トークンは短命 (つまりセッション ベース) で、リフレッシュ トークンは「生涯」であると考えられます。ユーザーにアプリケーションを再認証させるのではなく、リフレッシュ トークンを使用して新しいアクセス トークンを取得します。
最後に、OAuth 2.0 は、OAuth リクエストの処理を担当するサーバーとユーザー認証を処理するサーバーの役割を明確に分離することを目的としています。これに関する詳細は、前述の記事で詳しく説明されています。