7

この質問は、stackexchange および facebook API ( http://api.stackexchange.com/docs/authentication )に関するドキュメントに触発されていますが、おそらく一般的に OAUTH 2.0 により広く適用できます。

私の質問は、コンテンツへのアクセスを認証して取得するための暗黙的なモデルがはるかに単純に見えるのに、なぜ明示的な認証モデルを使用したいのですか?

暗黙的なアプローチによって暗示される制限はありますか。これは、技術的にはサーバー側のアプリですが、クライアント側の JavaScript ライブラリの使用に適していると思われる node.js アプリケーションに最適な方法です。

編集

いくつかの読み取りを行うと、Web クライアント フローの「暗黙の」性質は、リソース オーナー (ユーザー) がクライアント (Web ブラウザー) を暗黙的に信頼するという事実に由来するように見えます。これは、この暗黙の信頼が与えられていることを考えると、単純化されたフローが適切であることを意味します。

これは、OAUTH 2.0 を介して認証を実行するときに、リソース所有者 (ユーザー) がクライアントを暗黙的に信頼するかどうかについて警戒する必要があるという疑問につながります。これは、ユーザーに代わって認識と知識を前提としており、セキュリティ上の懸念につながる可能性があるため、潜在的に危険なスタンスのように思えます。

4

1 に答える 1

7

具体的には、stackexchange API ではなく OAuth 2.0 について言えば、暗黙的な許可フローとも呼ばれる暗黙的なフローにリスクの要素があります。これは、認可サーバーがアクセス トークンをユーザー エージェント/Web ブラウザーに送信するためです。

これによって生じる可能性のある損害を最小限に抑えるために、アクセス トークンは短命にされました。また、このシナリオでは、アクセス トークンは、ユーザーが承認したスコープに対してのみ使用できます。このタイプのフローは、主に、それらをサポートするサーバーを持たない単純な Web アプリに使用されます。Facebook で見られるかなりイライラするアプリがその例です。他のすべての開発者は、サーバーの手配を心配することなく、この暗黙的なフローを使用できます。

承認コード フローと呼ばれる明示的なフローは、はるかに安全です。これには、サーバーから認証コードを受信するユーザー エージェントが含まれます。このコードは、登録したアプリ (有効な資格情報を使用してバックエンドで維持するサーバー) でのみ使用できます。

例:-
Facebook グラフ API を使用する Google アプリがあるとします。Google アプリの Web サイトを開いて承認することができます
。i) ブラウザがトークンを受け取るか、Google アプリによって作成された Web ページが API にヒットし、データを取得してサーバーに返すことを確認します。
ii) または、ブラウザがトークンを取得し、ウェブページがそれを Google サーバーに返します。これにより、Google だけが Facebook API をヒットできるようになります (大企業の安心感)。また、すべてのリクエストを管理し、リクエスト/数/パターンを監視するためのあらゆる種類のメトリックを簡単に生成できる中央サーバーがあります。

この明示的なフローのもう 1 つの主な用途は、オフライン アクセスです。上記のシナリオでは、アプリ サーバーは更新トークンをフェッチし、ログインしていなくても REST API を呼び出すことができます。

サーバー側のアプリをお持ちの場合は、個人的には承認コード フロー/明示的なフローを使用することをお勧めします。

于 2013-05-21T09:25:34.373 に答える