web-dev-qa-db-ja.com

高レベルで、OAuth 2はどのように機能しますか？

私が理解しているように、Site-Aが ユーザー Site-Bからの情報にアクセスするために、OAuth 2では次の一連のイベントが発生します。

  1. Site-AはSite-Bに登録し、秘密とIDを取得します。
  2. User がSite-AにSite-Bへのアクセスを指示すると、 User はSite-Bに送信され、そこでSite-Bに特定の情報に対するSite-A権限を付与したいと伝えます。
  3. Site-Bは User を認証コードとともにSite-Aにリダイレクトします。
  4. その後、Site-Aはその認証コードをその秘密と共にSite-Bに渡し、セキュリティトークンと引き換えにします。
  5. それからSite-Aは User に代わってSite-Bへのリクエストをリクエストと一緒にセキュリティトークンをバンドルすることで行います。

セキュリティと暗号化に関して、これらすべてが高レベルでどのように機能するのでしょうか。 OAuth 2はセキュリティトークンを使用したリプレイ攻撃などからどのように保護されていますか？

oauth-2.0
544
William Jones

私が読んだものに基づいて、これはそれがすべてどのように機能するかです：

質問で概説されている一般的な流れは正しいです。ステップ2で、ユーザーXは認証され、サイトAからサイトBのユーザーXの情報へのアクセスも認証されます。ステップ4で、サイトは自分の秘密を認証し、認証コードと共にサイトBに返します。それは（ユーザーXのアクセストークン）を求めています。

全体として、OAuth 2は実際には非常に単純なセキュリティモデルであり、暗号化が直接機能することはありません。代わりに、シークレットとセキュリティトークンの両方が本質的にパスワードであり、全体がhttps接続のセキュリティによってのみ保護されています。

OAuth 2には、セキュリティトークンまたはシークレットのリプレイ攻撃に対する保護はありません。その代わりに、サイトBがこれらの項目を担当し、それらを持ち出さないようにし、送信中にhttpsを介して送信されることに完全に依存しています（httpsはURLパラメータを保護します）。

認証コードのステップの目的は単に便利であり、認証コードはそれ自体では特に敏感ではありません。これは、サイトBにユーザーXのアクセストークンを要求するときに、サイトAのユーザーXのアクセストークンに共通の識別子を提供します。同時に異なるサイトに配布されるのを待っている未解決のアクセストークンが多数ある可能性があるため、サイトBのユーザーXのユーザーIDだけでは機能しませんでした。

130
William Jones

OAuth 2.0が実際にどのように機能するのか

窓の中で最もおいしいドーナツを見たとき、私は仕事に行く途中オラフのパン屋さんで運転していました - つまり、チョコレートの良さが滴り落ちていたのです。それで私は中に入って、「そのドーナツを持っているに違いない！」と要求しました。彼は「確かにそれは30ドルになるだろう」と言った。

ええ、私は知っています、1つのドーナツのための30ドル！美味しいですね！突然、シェフが「いいえ、あなたのためにドーナツがない」と叫ぶのを聞いたとき、私は私の財布に手を伸ばしました。私は尋ねた：なぜ？彼は彼が銀行振替だけを受け入れると言った。

真剣に？うん、彼は真剣だった。私はすぐそこを離れて歩いたが、それからドーナツが私に声をかけて言った。ドーナツからの注文に従わないのは誰ですか？私はオーケーと言った。

彼は自分の名前（ドーナツではなく、シェフ）を書いたメモを私に渡しました。彼の名前はすでにメモに記されていたので、それが何を言っているのかがわかりませんが、大丈夫です。

私は私の銀行まで１時間半走りました。私はそのメモを窓口に渡しました。私は彼女のオラフが私に送ったと言った。彼女は私にそのような外見のうちの1つを与えました、「私は読むことができます」と言う種類。

彼女は私のメモを取り、私の身分証明書を要求し、彼に寄付するのにどれだけのお金を使ってもいいかと私に尋ねた。私は彼女に30ドルを言った。彼女はいくつかの落書きをして、私に別のメモを渡しました。これにはたくさんの数字がありました、私は彼らがどのように彼らがメモを追跡するかについてそれを推測しました。

その時点で私は飢えています。私はそこから急いで飛び出し、1時間半後に私はメモを書き留めたままオラフの前に立って戻ってきました。彼はそれを取り、それを見渡して「私は戻ってきます」と言った。

私は彼が私のドーナツを食べていると思ったが、30分後に私は不審になり始めた。そこで私はカウンターの後ろの人に "Where is Olaf？"と尋ねました。彼は「彼はお金を稼ぎに行った」と言った。 "どういう意味ですか？"。 「彼は銀行にメモを取ります」。

ええと…オラフは、銀行が私にくれて、私の口座からお金をもらうために銀行に戻ってきたというメモを取った。彼が銀行から私に渡されたメモを持っていたので、銀行は彼が私が話していた男であることを知っていました、そして私が銀行と話したので彼らは彼に30ドルしか与えないと知っていました。

私が見上げる時までに、オラフが私の前に立っていた ついに 私のドーナツを渡していたので、それを理解するのに長い時間を要したに違いありません。私が去る前に、私は「オラフ、あなたはいつもこのようにドーナツを売っていましたか？」と尋ねなければなりませんでした。 「いいえ、以前とは違うやり方でした」

ええと。車に戻っていると電話が鳴った。私は答えることを気にしませんでした、それはおそらく私を解雇することを求めている私の仕事でした、私の上司はそのような***です。そのうえ、私はちょうど私が通ったプロセスについて考えるのに追いついた。

私はそれについて考えることを意味します：私は彼に私の口座情報を与える必要なしに私の銀行口座からOlafに30ドルを引き出させることができました。私はすでに銀行に30ドルしか払えないと言っていたので、私は彼があまりにも多くのお金を出すことを心配する必要はありませんでした。そして銀行は彼が彼らが私にオラフに与えるために与えたメモを持っていたので彼が正しい人であることを知っていました。

わかりました、私のポケットから30ドル引き渡すほうがよいでしょう。しかし彼がそのメモを持っていたので私はちょうど彼に毎週30ドルを取るように銀行に言うことができましたそして私はパン屋でちょうど現れることができましたそして私はもう銀行に行く必要はありませんでした。電話でドーナツを注文することもできます。

もちろん、私は決してそれをしません - そのドーナツは嫌でした。

このアプローチにはもっと広い用途があるのだろうか。彼はこれが彼の2番目のアプローチであると述べました、私はそれをOlaf 2.0と呼ぶことができます。とにかく私は家に帰ることをお勧めします、私は新しい仕事を探し始めました。でも、街の向こうのあちらこちらで、いちごの揺れが起きる前に、そのドーナツの味を洗い流すために何かが必要です。

1346
Luis Perez

OAuthは、他社のWebサイトに保存されているデータにアカウントやパスワードを入力しなくても3者アプリからアクセスできるようにするプロトコルです。より正式な定義については、Wikiまたは仕様書を参照してください。

これがユースケースのデモです。

  1. LinkedInにログインして、Gmailの連絡先にいる友達を何人か接続したいです。 LinkedInはこれをサポートしています。それはgmailから安全なリソース（私のgmailの連絡先リスト）を要求します。だから私はこのボタンをクリックします：
    Add Connection

  2. アカウントとパスワードを入力すると、Webページがポップアップ表示され、Gmailのログインページが表示されます。
    Add Connection

  3. Gmailが同意ページを表示し、そこで[同意する]をクリックします。 Add Connection

  4. 今すぐLinkedInはGmailで私の連絡先にアクセスすることができます。 Add Connection

以下は上記の例のフローチャートです。

Add Connection

ステップ1：LinkedInはGmailの認証サーバーにトークンを要求します。

ステップ2：Gmail認証サーバーはリソースの所有者を認証し、ユーザーに同意ページを表示します。 （まだログインしていない場合、ユーザーはGmailにログインする必要があります）

ステップ3：ユーザーがLinkedInにGmailデータへのアクセス要求を許可します。

ステップ4：Gmail認証サーバーがアクセストークンを返信します。

ステップ5：LinkedInはこのアクセストークンを使ってGmail APIを呼び出します。

ステップ6：アクセストークンが有効な場合、Gmailリソースサーバーは連絡先を返します。 （トークンはGmailリソースサーバーによって検証されます）

OAuthについての詳細からもっと多くの情報を得ることができます ここ 。

100
Owen Cao

RFC6750 から持ち上げられた図1

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+
24
8bitjunkie

これがOauth 2.0のしくみです。 この記事の中で説明されています

enter image description here

13
Suraj

これは宝石です。

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

非常に簡単な要約：

OAuthは4つの役割を定義します。

  1. リソース所有者
  2. クライアント
  3. リソースサーバー
  4. 認証サーバ

あなた（リソース所有者）は携帯電話を持っています。複数の異なるEメールアカウントがありますが、すべてのEメールアカウントを1つのアプリにまとめたいので、切り替えを続ける必要はありません。あなたのGMailアプリケーションで両方の電子メールを読むことができるようにあなたのGMail（クライアント）はあなたのYahoo電子メール（リソースサーバ）への（Yahooの認証サーバを介した）アクセスを要求します。

OAuthが存在する理由は、GMailがあなたのYahooユーザー名とパスワードを保存するのは安全ではないからです。

enter image description here

10
Belfield

もう一つの答えは非常に詳細であり、OPによって提起された質問の大部分を取り上げています。

詳しく述べると、特に「セキュリティトークンを使ったリプレイ攻撃のようなものに対してOAuth 2はどのように防御するのですか」というOPの質問に対処するために、 implementation OAuth 2の公式勧告にはさらに2つの保護があります。

1）トークンは通常有効期限が短くなります（ http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ）：

トークンの有効期限が短いことは、次の脅威に対する保護の手段です。

  • 再生中...

2）トークンがサイトAによって使用される場合、推奨はURLパラメータとしてではなくAuthorization requestヘッダーフィールド（ http://tools.ietf.org/html/rfc6750 ）に表示されることです。

クライアントは、「認証」リクエストヘッダフィールドと「認証」HTTP認証スキームを使用して、認証されたリクエストを認証トークンで発行する必要があります（SHOULD）。 ...

"application/x-www-form-urlencode"メソッドは、参加しているブラウザが "Authorization"リクエストヘッダフィールドにアクセスできないアプリケーションコンテキストを除いては使用すべきではありません。 ...

URI Query Parameter ...は現在の使用法を文書化するために含まれています。そのセキュリティ上の欠陥から、その使用はお勧めできません。

7
Will

OAuth2が4つの付与タイプすべて、つまりアプリがアクセストークンを取得できる4つの異なるフローでどのように機能するかについての最も簡単な説明がここにあります。

類似性

すべての補助金タイプフローには2つの部分があります。

  • アクセストークンを取得する
  • アクセストークンを使用する

2番目の部分'use access token'はすべてのフローで同じです

違い

各付与タイプのフローの最初の部分'get access token'は異なります。

しかし、一般的に'get access token'の部分は5つのステップからなるものとして要約することができます。

  1. クライアントIDを取得するために、TwitterなどのOAuthプロバイダにアプリ（クライアント）を事前登録します。
  2. クリックされたユーザーが認証されるためにOAuthプロバイダーにリダイレクトされるようにあなたのページ上でクライアントIDと必要なスコープ/パーミッションを持つソーシャルログインボタンを作成します
  3. OAuthプロバイダがユーザーにアプリへの許可を与えるように要求します（クライアント）
  4. OAuthプロバイダーがコードを発行
  5. アプリ（クライアント）がアクセストークンを取得

ここでは、5つのステップに基づいて各付与タイプのフローがどのように異なるかを比較して並べた図を示します。

この図は、 https://blog.oauth.io/introduction-oauth2-flow-diagrams/ からのものです。

enter image description here

それぞれ異なるレベルの実装上の難しさ、セキュリティ、そしてユースケースがあります。あなたのニーズと状況に応じて、あなたはそれらのうちの1つを使わなければならないでしょう。どちらを使う？

クライアント資格情報 ：アプリが単一のユーザーにのみサービスを提供している場合

リソース所有者のパスワード認証情報 ：これは、ユーザーが自分の認証情報をアプリに渡す必要があるため、最後の手段としてのみ使用する必要があります。

認証コード ：ユーザー認証を受けるための最良の方法

暗黙的 ：アプリがモバイルまたはシングルページアプリの場合

ここに選択のより多くの説明があります： https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/ /

2
nethsix