37

問題：

ローカル認証戦略のみを使用して、安全な API をクライアント側アプリに提供します。
赤い矢印は知識ギャップの一部です。

ここに画像の説明を入力

環境：

つまり ---のようなGETサービスにアクセスできる場所にPOSTをclient.example.com作成しています。api.example.com/loginclient.example.comapi.example.com/secret

アイデア！

API の前にあるハイブリッド許可タイプによる OAuth 2.0 の実装。

なぜハイブリッド？

  • APIサーバーへのリダイレクトもアクセストークンの付与もないため、Implicit Grant Flow別名ではありません。Client-Side Web Applications Flow(ie) 「誰々があなたのデータにアクセスしても大丈夫ですか?」

  • クライアント ID とクライアント シークレットが要求と共に渡されるため、クライアント アプリはサーバー側であると想定されるResource Owner Password Flowため、これは問題ではありません。

わかりました...では、両方とも少しはどうでしょうか?

クライアント側アプリのページ読み込み時に CRSF トークンを使用し、アクセス トークンと交換する OAuth 2.0 認証エンドポイントとユーザー資格情報を POST するとどうなるでしょうか? ログインが成功したら、後続の各リクエストをアクセス トークンと CRSF トークンで認証します。

私が見つけた良い Node.js OAuth 2.0 ライブラリ:

https://github.com/ammmir/node-oauth2-provider

助けて！

この問題を解決する認証手段の実例が見つかりません! 私を正しい方向に向けますか？

最終的に、ここでの目標は、上記の規則が不可能であっても、CORS をローカル戦略 (ユーザー名とパスワード) を使用して REST API に対してクライアント側アプリを認証することです。

報奨金に対応するには:

これはクライアント側のアプリなので、トレンディにしましょう。

上記のNode.js OAuth 2.0 シードを API/Auth サーバーに使用し、Angular.jsやBackbone.jsなどのフロント エンド フレームワークを使用してリクエストを行う実際の例を探しています。

例は、上記のコンテキストと一致する必要があります。

4

5 に答える 5

1

賞品を狙う回答ではありません。ちょうど私の2セント:)

私のウェブサーバーでは、

httpsを介した基本認証を使用して、ログイン/パスワードを使用した残りの呼び出しで認証を行います。この呼び出しは、キーをクライアント (1 ページの Web アプリ) に配信します。

その後のすべての REST 呼び出しは、キーで署名されます。サーバーは署名が正しいことを確認し、すべてがまだ https で行われます。

このメカニズムはかなり使われていると思います。

クロスドメインの問題はわかりません。単一のソースがあり、別のソースから何かが必要な場合は、JSONP を使用します。

nginx を https->http フォワーダとして使用しています。

OAuth2 ソリューションと競合する方法がわからない。

于 2013-04-24T07:04:46.090 に答える
0

実際の例を書く時間があるとは約束できませんが、2つのパスを示すことができます:)

最大の取引はCORSです。この問題を解決した後は、$httpサービスを簡単に使用できます。したがって、最初に、おそらく最も簡単なのは、api.x.com を指す x.com Web サーバーでリバース プロキシを構成することです。ここに記事を書きました

2 番目のアプローチはより優れており、特定のドメインがリソースを使用することを承認するために、まさにこの目的のために作成されました。api.x.com で少しコーディングする必要があるため、他のドメインで提供される新しい Web アプリケーションを変更する必要はありません。api.x.com サービスで CORS リクエストを承認するだけです。

  • 承認済みドメインのリストを管理できるデータベースにテーブルを作成します
  • そのテーブル レコード「x.com」に追加します。
  • api.x.com にリクエスト フィルター/インターセプターを追加し、リクエストが処理された後に呼び出す必要があるメソッドに使用する技術用語を追加しAccess-Control-Allow-Origin: x.com、リクエストが x.com から送信された場合に応答を追加します (つまり、リクエスト ヘッダーの参照値の一致を確認します)。上記の表の任意の値を取得し、その値を Access-Control-Allow-Origin 応答ヘッダーに入れます)。

それだけです :) この後、 $httpまたはjQuey.ajaxの使用方法を知っていれば、許可されたドメインから api.x.com へのリクエストを数分で POST/PUT/DELETE/... できるようになります。

于 2013-04-23T22:39:46.150 に答える
0

私はvinilla js Webアプリとクロスドメイン認証をGAEバックエンドまたはOpenID接続に使用するという非常に似た考えを持っています。

Web アプリは CDN で実行されます。ログイン リンクをクリックすると、それぞれのログイン サーバーに移動し、Web アプリにリダイレクトされます (XSRF セキュリティ トークンと HTTPS のみの Cookie を使用)。ログイン サーバーは、認証情報を使用してクロス ドメイン リクエストを受け入れます。XSRF トークンは、リクエストごとに (ヘッダーで) 設定する必要があります。Cookie はブラウザによって設定されます。HTTP のみの Cookie であるため、JS では読み取ることができません。この技術は非常に安全です。

ログインすると、ログインサーバーからセキュアアセスメントを取得できます。

詳細な説明については、こちらとオープン ソースリポジトリをご覧ください。

于 2013-04-29T01:35:04.460 に答える