facebook - Facebook OAuth 2.0 の「コード」と「トークン」

Question

https://developers.facebook.com/docs/authentication/で説明されているように、Facebook OAuth2 認証フローで「コード」と「トークン」の両方が必要なのはなぜですか?

OAuth ダイアログリファレンス ( https://developers.facebook.com/docs/reference/dialogs/oauth/ ) を見ると、ユーザーに関する情報を取得するためにのみトークンを使用しているように見えます。またはresponse_typeとしてパラメーターを指定すると、最初にトークンを取得します。tokencode,token

トークンを直接取得するのではなく、「コード」を取得してから、そのコードを使用して「トークン」を取得する必要があるのはなぜですか?

OAuthの仕組みについて基本的なことを誤解していると思いhttps://graph.facebook.com/oauth/access_tokenますが、ダイアログで初めてトークンを取得すると、リクエストを完全に回避しているようです。

score 30 · Accepted Answer

Salesforce ドキュメントから厚かましく拝借:

認証コード

認可コードは、認可サーバーによって作成され、ブラウザ経由でクライアントアプリケーションに渡される、ユーザーのアクセス許可を表す有効期間の短いトークンです。クライアントアプリケーションは、承認コードを承認サーバーに送信して、アクセストークンと、必要に応じて更新トークンを取得します。

アクセストークン アクセストークンは、エンドユーザーに代わって認証された要求を行うためにクライアントによって使用されます。認証コードよりも有効期間が長く、通常は数分または数時間です。アクセストークンの有効期限が切れると、それを使用しようとすると失敗し、更新トークンを介して新しいアクセストークンを取得する必要があります。

score 23 · Accepted Answer

OAuth 2.0 仕様から:

認可コードは、クライアントを認証する機能や、アクセストークンをリソースオーナーのユーザーエージェントを介さずにクライアントに直接送信する機能など、いくつかの重要なセキュリティ上の利点を提供します。 .

つまり、基本的に - 主な理由は、アクセストークンを取得するアクターの数を制限することです。

「トークン」応答は、主にブラウザーに存在するクライアント (例: JavaScript クライアント) を対象としています。

score 9 · Accepted Answer

クライアントアプリではなく、ユーザーが自分自身に代わって認証サーバー（つまり、facebook）に対して認証するため、混乱が生じました。クライアントアプリ (https を使用) を保護してから、ユーザーエージェント (ブラウザー) を保護するのは非常に簡単です。

IETF-oauth ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-threatmodel-08#section-3.4 ) からの元の定式化は次のとおりです。

3.4. 認証コード

認証コードは、成功したエンドユーザーの認証プロセスの中間結果を表し、クライアントがアクセスと更新トークンを取得するために使用します。認証コードは、2 つの目的で、トークンの代わりにクライアントのリダイレクト URI に送信されます。

ブラウザーベースのフローは、URI クエリパラメーター (HTTP リファラー)、ブラウザーキャッシュ、またはログファイルエントリを介して潜在的な攻撃者にプロトコルパラメーターを公開し、リプレイされる可能性があります。この脅威を軽減するために、トークンの代わりに有効期間の短い認証コードが渡され、クライアントと認証サーバー間のより安全な直接接続を介してトークンと交換されます。
間接的な認可リクエストのコンテキストよりも、クライアントと認可サーバー間の直接的なリクエスト中にクライアントを認証する方がはるかに簡単です。後者はデジタル署名を必要とします。

score 3 · Accepted Answer

基本的に、Lix の answer の拡張として、アクセスコードルートを使用すると、リソースオーナー (つまり Facebook ユーザー) は、たとえばログオフすることによって、オフラインクライアント (つまり、あなたの申請）。これが重要でない場合は、アクセスコードルートを使用する必要はありません。

さらに、サーバーに提供されたトークンが実際にリソース所有者 (つまり、Facebook ユーザー) に登録され、ユーザーエージェント (または中間者) に登録されていないことを確認するために、アクセスコードが提供されます。

これは、暗黙的付与フローと認可コード付与フローのどちらを選択するかという問題に似ているようです。実はここが逆の視点のように見える!? .

また、ドリューが述べたように、

アクセストークンの有効期限が切れると、それを使用しようとすると失敗し、更新トークンを介して新しいアクセストークンを取得する必要があります。

もう 1 つの部分は更新トークンですが、FB ドキュメントで十分に説明されているとは思いません。私が正しければ、暗黙の許可 (直接トークン) は本当に短命であるはずですが、それは施行される予定であり、FB.js はその多くを隠しているようです (これは私が深く調べていないものです)。 .

私が正しければ、これcode%20tokenは、ユーザーエージェントがトークンを持つことと、サーバーが単一の要求でトークン交換プロセスを開始できることの両方を可能にする最適化です (ネットワーク IO を介したものは、特にユーザーエージェントにとって高価であると見なされるため)。 .

score 2 · Accepted Answer

OAuth 2.0 with facebook では、全体的なコンセプトは次のように単純です。

Step 1. GETリクエストで「Authorization Code」を取得する

request URI: https://www.facebook.com/dialog/oauth
Params:
    response_type=code
    client_id={add your "App id" got by registering app}
    redirect_uri={add redirect uri defined at the registration of app}
    scope={add the scope needed in your app}
Headers: None

ステップ 2. POST リクエストとして認証コードを送信して「アクセストークン」を取得する

    URI: https://graph.facebook.com/oauth/access_token
    Params:
        grant_type=authorization_code
        client_id=<add your "App id" got by registering app>
        redirect_uri=<add redirect uri defined at the registration of app>
        code=<obtained authorization code from previous step>
    Headers:
        Authorization:Basic encode <App Id:App Secret> with base64 
        Content-Type:application/json

ステップ 3. 上記のステップで取得したアクセストークンを使用して、ユーザーリソースを取得します。

score -1 · Accepted Answer

ユーザーがログインしたときにトークンを受け取ります。ただし、他のアクションを実行しているときにトークンを変更したい場合があります。アプリ/ページとしてのEG投稿、または。を使用したユーザーとしての投稿offline_access。

facebook - Facebook OAuth 2.0 の「コード」と「トークン」

11 に答える 11

Related

Reference