OAuth 2とOAuth 1の違いは何ですか？

604

非常に簡単に言えば、誰かがOAuth 2とOAuth 1の違いを説明できますか？

OAuth 1は現在廃止されていますか？OAuth 2を実装する必要がありますか？OAuth 2の実装はあまり見かけません。ほとんどはまだOAuth 1を使用しているため、OAuth 2を使用する準備ができているとは思えません。それは...ですか？

oauth oauth-2.0 authorization

— サリバン
ソース

どうか明らかにしてください; stackoverflow.com/questions/9565744/…–

— 学習者、

OAuthの簡潔な説明と詳細なフロー（図を含む）を確認したい

— Chris Ismael

あなたはここにあなたの答えを見つけたことはOAuth 2.0 -概要

— ジョン・ジョー

529

Eran Hammer-Lahavは、彼の記事Introducing OAuth 2.0の違いの大部分を説明する優れた仕事をしました。要約すると、主な違いは次のとおりです。

非ブラウザーベースのアプリケーションのサポートを改善するためのより多くの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要求の処理を担当するサーバーとユーザー認証を処理するサーバーの間で役割を明確に分離することを目的としています。 詳細については、前述の記事を参照してください。

— ヴィルコーダー
ソース

2

oauth 1と2でコールバックURLがどのように異なるかを誰かが明確にできますか？

— ブライアンアームストロング

2

OAuth 2.0は、RFCとして承認されている場合にのみ廃止されます。現在はインターネットドラフトですが、インターネット標準になる予定です（これらの計画が可能な限り）。ただし、フレームワークの大部分がまだ指定されていないため、これには数年かかります。おそらく、今後数年でインターネットドラフトのファミリー全体が公開され、それぞれがOAuth 2.0承認フレームワークのさまざまな側面に関するものになるでしょう。これが本当の、訪問のある理由を確認するにはtools.ietf.org/html/draft-ietf-oauth-v2、そして「この仕様の範囲を越えて」を検索;）

— HåvardGeithus

48

：記事の著者はここで読むことができる「OAuth 2.0のと地獄への道」と呼ばれるフォローアップ昨年、書いたweb.archive.org/web/20120731155632/http://hueniverse.com/2012/...を 2つの重要な違いはセキュリティです。2.0には暗号化機能がないために予見されていました。

— kdazzle 2013

4

OAuth 1.0のセキュリティは、クライアントアプリケーションに埋め込まれた秘密鍵を機密に保つことができるという前提に基づいていますが、前提は単純です。OAuth 2.0では、このような単純なクライアントアプリケーションは機密クライアントと呼ばれます。OAuth 1.0クライアントとOAuth 2.0機密クライアントのセキュリティレベルには、実際的な違いはありません。「OAuth 2.0と地獄への道」はこの点を逃しています。

— 川崎貴彦

6

@kdazzle、そのリンクはここに移動しました：hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

— e_i_pi

193

ここで素晴らしい答えを見つけましたが、見逃していたのはいくつかの図でした。SpringFrameworkを使用する必要があったので、私はそれらの説明に出会いました。

次の図は非常に役立ちます。OAuth2とOAuth1の関係者間の通信の違いを示しています。

OAuth 2

ここに画像の説明を入力してください

OAuth 1

ここに画像の説明を入力してください

— nyxz
ソース

3

このフローで「client_secret」はどこで使用されていますか？

— ashwintastic 2016年

3

ユーザーがプロバイダー（Facebook、Twitter、Googleなど）にリダイレクトされたときに入力するシークレットを意味する場合、これはのステップ2 OAuth 2とステップ4になりOAuth 1ます。

— nyxz

なぜ両方の図に「ユーザー許可承認」と呼ばれるサービスプロバイダーステップがあるのですか？これは逆または間違っているようです。「ユーザー」は承認を求めるものではありませんか？

— Forbin

@Forbinこのステップはサービスプロバイダー側で行われるため。サービスに必要な許可が表示されるページにアクセスし、認証しようとしているサービスとこの情報を共有することに同意する必要があります。StackOverflowには、実際にはGoogleアカウントを使用してログインするオプションがあります。同じように機能します。SOはGoogleにあなたのメールを表示するように要求し、あなたはそれに同意する必要があります。

— nyxz

91

これまでの説明はすべて非常に詳細で複雑なIMOです。簡単に言うと、OAuth 2はセキュリティをHTTPSプロトコルに委任します。OAuth 1はこれを必要としなかったため、さまざまな攻撃に対処するための代替方法がありました。これらの方法では、複雑で実装が困難な特定のセキュリティプロトコルをアプリケーションで実行する必要がありました。したがって、アプリケーション開発者がHTTPSについて心配する必要がないように、セキュリティをHTTPSに依存するほうが簡単です。

他の質問については、答えは異なります。HTTPSの使用を必要としないサービス、OAuth 2より前に開発されたサービス、またはOAuth 2の使用を妨げるその他の要件があるサービスもあります。さらに、OAuth 2プロトコル自体については多くの議論があります。ご覧のように、Facebook、Google、およびその他いくつかのプロトコルには、それぞれ異なるバージョンのプロトコルが実装されています。したがって、異なるプラットフォーム間でより均一になるため、一部の人々はOAuth 1を使用しています。最近、OAuth 2プロトコルが完成しましたが、どのように採用されるかはまだわかりません。

— チャチャム15
ソース

11

つまり、基本的にOAuth2はHTTPSで動作するため、OAuth1よりもシンプルです。OAuth1はHTTPSなしで動作できるため、もう少し複雑にする必要がありますか？

— マイクロ

@MicroRこれはあなたがそこから得た1つの実用的な定義です！;）

— EralpB 2017年

36

Oauth 2の使用に対する重大なセキュリティの引数があることに注意してください。

ひどい記事

そしてより技術的なもの

これらはOauth 2の筆頭著者によるものです。

キーポイント：

Oauth 1はトランスポートに依存しませんが、Oauth 2はSSLに加えてセキュリティを提供しません。
ある意味では、SSLは安全ではありません。サーバーは接続を検証せず、一般的なクライアントライブラリを使用すると、失敗を簡単に無視できます。

SSL / TLSの問題は、クライアント側で証明書を検証できない場合でも、接続が機能することです。エラーを無視して成功する場合はいつでも、開発者はそれを実行します。サーバーには証明書の検証を強制する方法がありません。それが可能であったとしても、攻撃者は確かにそうしません。
OAuth 1.0で実行するのがはるかに難しい、セキュリティのすべてを手探りで削除できます。

2番目によくある潜在的な問題はタイプミスです。1つの文字（「https」の「s」）を省略するとトークンのセキュリティ全体が無効になるので、適切な設計だと思いますか？または、リクエストを（有効で検証済みのSSL / TLS接続を介して）間違った宛先（たとえば、「http://gacebook.com」？コマンドラインからOAuthベアラートークンを使用できることは、明らかにユースケースベアラートークンの支持者が推進していたことを覚えておいてください。

— djechlin
ソース

4

「typo」引数はあまり有効ではありません。httpからhttpsにリダイレクトするのが一般的です

— Oleg Mikheev

2

@OlegMikheevええ、しかし、MITMがあなたのヘッダーを盗聴することを許可するのにたった1つのhttp（no-s）リクエストが必要であり、あなたのトークンは他の誰かによって使用されています！

— Patrick James McDougle 2015年

3

ヘッダーがクッキーを意味する場合、それらは安全であると考えられます。それ以外は、ユーザーのタイプミス（ブラウザーのURL）がどのようにトークンを公開できるかはわかりません。それらはヘッダーにあるはずです

— Oleg Mikheev

2

「typo」引数に対する追加のポイントとして、サービスプロバイダーは、httpsを経由しないOAuth 2.0要求を拒否し、その要求のアクセストークンを取り消すことができます。

— skeller88 2015年

32

OAuth 1.0プロトコル（RFC 5849）のセキュリティは、クライアントアプリケーションに埋め込まれた秘密鍵を機密に保つことができるという前提に依存しています。ただし、この仮定は単純です。

OAuth 2.0（RFC 6749）では、このような単純なクライアントアプリケーションは機密クライアントと呼ばれます。一方、秘密鍵の秘匿が困難な環境にあるクライアントアプリケーションをパブリッククライアントと呼びます。2.1を参照してください。詳細については、クライアントタイプ。

その意味で、OAuth 1.0は機密クライアント専用の仕様です。

「OAuth 2.0 and the Road to Hell」は、OAuth 2.0は安全性が低いと述べていますが、OAuth 1.0クライアントとOAuth 2.0機密クライアントのセキュリティレベルには実際的な違いはありません。OAuth 1.0は署名を計算する必要がありますが、クライアント側の秘密鍵を機密に保つことができることがすでに保証されている場合、セキュリティは強化されません。シグネチャの計算は、実用的なセキュリティを強化することなく、面倒な計算です。私は、TLSを介してサーバとちょうどプレゼントにOAuth 2.0のクライアント接続されていることを簡潔に比べて、平均値client_idとはclient_secret、面倒な計算は、セキュリティの面で優れていると言うことはできません。

さらに、RFC 5849（OAuth 1.0）はオープンリダイレクタについて何も言及していませんが、RFC 6749（OAuth 2.0）は言及しています。つまりoauth_callback、OAuth 1.0のパラメーターがセキュリティホールになる可能性があります。

したがって、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 機密クライアントも同じ条件に依存しています。条件がすでに満たされている場合、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は機密クライアントとサポートされるパブリッククライアントのプロトコルも簡素化したということです。よく知られているかどうかに関係なく、スマートフォンアプリケーションはパブリッククライアント（RFC 6749、9）として分類され、OAuth 2.0の恩恵を受けます。

— 川崎貴彦
ソース

7

HTTP、HTTPSなどを介して、シグネチャの代わりにシークレットを送信すると、プロトコルレベルのMITMにより、常に暗黙のセキュリティリスクが発生します。これで、シークレットを見つける方法が2つあります。1つだけではなく、デバイスをroot化するか、root証明書を偽造します（以前に発生したため、あまりフェッチされていません）。セキュリティモデルが「ええ、トランスポートに処理を任せる」の場合、プロトコルより安全性が低くなることはありません。ただし、モノリシックセキュリティモデル==多くのサービスの1つのエントリポイント。実用的なエンジニアにとっては「十分」ですが、代替の分散型モデルほど「安全」ではありません。

— マークG.16年

23

トークンが生成されたら、実際のAPI呼び出しにOAuth 2.0署名は必要ありません。セキュリティトークンは1つだけです。

OAuth 1.0では、クライアントがAPI呼び出しごとに2つのセキュリティトークンを送信し、両方を使用して署名を生成する必要があります。リクエストを検証するには、保護されたリソースのエンドポイントがクライアントの認証情報にアクセスできる必要があります。

ここでは、OAuth 1.0と2.0の違いと、両方がどのように機能するかについて説明します。

— フィオナ・ミラー
ソース

22

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は安全でない実装を生成する可能性があります。

— トニー・ニブ
ソース

7

リンクのみの回答はお勧めできません。参照は時間の経過とともに古くなる傾向があります。参照としてリンクを維持しながら、ここにスタンドアロンの概要を追加することを検討してください。

— クレオパトラ2013年

6

OAuth 1.0のセキュリティは、クライアントアプリケーションに埋め込まれた秘密鍵を機密に保つことができるという仮定に依存していますが、スマートフォンアプリケーションの場合、その仮定は単純です。OAuth 2.0では、このような単純なクライアントアプリケーションは機密クライアントと呼ばれます。OAuth 1.0クライアントとOAuth 2.0機密クライアントのセキュリティレベルには、実際的な違いはありません。「OAuth 2.0と地獄への道」はこの点を逃しています。

— 川崎貴彦

15

高度な説明が必要な場合は、両方の仕様を読む必要があります。

https://oauth.net/core/1.0a/

https://oauth.net/2/

フローの違いについて明確な説明が必要な場合、これが役立ちます。

OAuth 1.0フロー

クライアントアプリケーションは、Twitterなどのプロバイダーに登録します。
Twitterは、そのアプリケーションに固有の「コンシューマシークレット」をクライアントに提供します。
クライアントアプリは、独自の「コンシューマーシークレット」を使用して、TwitterへのすべてのOAuthリクエストに署名します。
OAuthリクエストのいずれかの形式が正しくない、データが欠落している、または不適切に署名されている場合、リクエストは拒否されます。

OAuth 2.0フロー

クライアントアプリケーションは、Twitterなどのプロバイダーに登録します。
Twitterは、そのアプリケーションに固有の「クライアントシークレット」をクライアントに提供します。
クライアントアプリケーションには 「クライアントシークレット」が含まれ、すべてのリクエストは一般にhttpヘッダーとして含まれます。
OAuthリクエストのいずれかの形式が正しくない、データが欠落している、または間違ったシークレットが含まれている場合、リクエストは拒否されます。

ソース：https : //codiscope.com/oauth-2-0-vs-oauth-1-0/

— JRichardsz
ソース

2

看板の太字が見えますか？機能的なものも同じ概念を持つ可能性がありますが、技術的には単純なヘッダー（oauth2）を使用します。リクエスト全体に署名するのは非常に異なります。回答を役に立たないとマークする前に注意を払い、読解力を向上させる

— JRichardsz

1

自分の答えを読んで、それを理解してみてください。「すべてのリクエストに秘密で署名する」および「すべてのリクエストで秘密を送信する」。彼がすでにそれらを使用していない限り、彼らの正しい心の中の誰もここで違いを理解するつもりはありません。私は違いを知っていますが、OPは違います。この答えはOPをさらに混乱させるだけなので、反対票を投じます。そのようなあいまいな答えは反対票に値します。より具体的で有益な他の回答をここで読んでください。

— saran3h

12人の開発者がそれを手に入れました。oauth1とoauth2には多くの違いがあります。以前の回答はそれらをカバーし、私が言ったように、あなたはあなた自身の答えを作るためにこのoauth.net/core/1.0aまたはこのoauth.net/2を読むことができます。私の目標は、開発者がレストクライアントを開発する必要があるときに、最も悪名高い技術的な違いの 1つを示すことです。

— JRichardsz

7

OAuth 2.0は、以下の方法で物事を簡素化することを約束します。

トークンの生成に必要なすべての通信にはSSLが必要です。これらの複雑な署名が不要になったため、これは複雑さが大幅に減少します。
トークンが生成されたら、実際のAPI呼び出しに署名は必要ありません。SSLもここで強くお勧めします。
トークンが生成されると、OAuth 1.0では、クライアントがすべてのAPI呼び出しで2つのセキュリティトークンを送信し、両方を使用して署名を生成する必要がありました。OAuth 2.0にはセキュリティトークンが1つしかなく、署名は必要ありません。
プロトコルのどの部分がAPIを実装する実際のサーバーである「リソース所有者」によって実装され、どの部分が別の「承認サーバー」によって実装されるかが明確に指定されています。これにより、Apigeeなどの製品が既存のAPIにOAuth 2.0サポートを提供しやすくなります。

出典：http : //blog.apigee.com/detail/oauth_differences

— アビジット・ガイクワッド
ソース

1

セキュリティの観点から、私はOAuth 1を選びます。OAuth2.0と地獄への道を参照してください

そのリンクからの引用：「現在1.0を正常に使用している場合、2.0は無視してください。1.0を超える本当の価値はありません（クライアント開発者が1.0の署名をすでに理解していると思います）。

この分野に不慣れで、自分をセキュリティの専門家だと考えている場合は、その機能を注意深く調べてから2.0を使用してください。エキスパートでない場合は、1.0を使用するか、信頼できるプロバイダーの2.0実装をコピーして正しく実装します（FacebookのAPIドキュメントが最初の出発点として最適です）。大規模には2.0の方が適していますが、大規模な運用を行っている場合は、サイトにセキュリティの専門家がいて、すべてを理解してくれるでしょう。」

— 害
ソース