21

OAuth1.0aを使用してアプリケーションを認証するAPIがあります。これは、非推奨になっているカスタムビルドおよびhodge-podge呼び出しの数を使用していた古いAPIを置き換えています。

OAuth 1.0aは、コンシューマーシークレットが秘密に保たれていることに依存しているため、（クライアント側の）Javascriptでは安全ではないことはよく知られています。ソースは常に表示可能であるため、これは不可能です。

Chrome、Firefox、IE、Safari用のブラウザ拡張機能があり、将来このAPIを使用する必要があります。これらの拡張機能はすべてJavascriptで大部分または完全に記述されているため、セキュリティの問題があります。

これらの拡張機能は社内にあるため、アクセストークンを取得するためのカスタム認証方法を使用できます。

私が実装を計画しているのは次のとおりです。

  • ユーザーはブラウザでWebサイトにログインします。
  • Webサイトは、セッションキーを使用してCookieを発行します。
  • 次に、拡張機能はそのCookieを取得し、それをAPIに渡します。
  • APIは、それが有効でアクティブなセッションであることを検証し、拡張機能にアクセストークンを発行します。
  • これらのトークンは、有効期限が切れる前に最大1時間持続します。
  • また、JavaScriptで発行されたCookieにはレート制限が低くなります。

次の前提で動作します。

  • 別のアプリケーションがあなたのCookieにアクセスできる場合、それらはとにかくWebサイトであなたになりすますことができるため、APIへのアクセスも同じです。
  • すべての認証方法は、引き続き当社の管理下にあります。
  • トークンの定期的な有効期限は、トークンが危険にさらされた場合、悪用される時間が限られていることを意味します。

私の質問は、これはAPIへのアクセスを制限する安全な方法ですか？より良いものはありますか？

いくつかのメモ。 Chrome拡張機能は、特定のサイトのCookieにアクセスするための許可を求めることができるという事実を知っています。Firefoxの拡張機能でもそうできると思います。

明らかに、どのページでもjavascriptを介してCookieにアクセスすることは望ましくありません。そうしないと、XSS攻撃にさらされるため、拡張機能を介してのみアクセスする必要があります。

4

3 に答える 3

8

OAuth用のjavascriptライブラリを介してOAuthログインを行うサイトを作成しました。これがワークフローです。

  1. OAuthは、LocalStorageを備えたブラウザでのみサポートされます
  2. ログインフォームは、LocalStorageでOAuthキーを確認し、OAuthキーが存在する場合は自動的にOAuthログインを試行します。
  3. ログインフォームに「rememberme」のチェックボックスがあるので、ユーザーはログイン時にOAuthトークンを作成できます。
  4. ログインに成功すると、次のことを覚えておいてください。
    • User Agentと同じ名前のClientApplicationを検索または作成し、必要に応じてトークンを作成します
    • HTML応答でjavascriptタグを使用して応答します。javascriptタグは、引数として渡されたトークンを使用してjavascript関数を呼び出します。この関数は、OAuthトークンをLocalStorageに保存します。
  5. OAuthログインの試行が失敗すると、次のようになります。
    • HTML応答でjavascriptタグを使用して応答します。javascriptタグは、javascript関数を呼び出して、OAuthトークンのLocalStorage設定をクリアします。これにより、追加のOAuthログイン試行が防止されます

このプロセスにはもう少し詳細があります。必要に応じて、詳しく説明します。

于 2011-06-09T15:53:45.420 に答える
3

後でこの投稿に来る人のためのほんの少しの考え：

  1. 「これは安全ですか」->どの脅威から保護したいかによって異なります。以下の点で、ソリューションはすでに信頼できるネットワークリンクを暗示していると想定します（転送中のトークンまたは資格情報の傍受の試みを防ぐため）。ただし、APIを許可されていないユーザー（人間）から保護するのか、許可されていないAPIクライアント（ブラウザー内で実行されている不正な拡張機能など）から保護するのかについては言及されていないため、説明には重要な要素がありません。前者は利用可能なオープンスタンダードで非常に簡単に達成できますが、モデルは基本的にオープンソースのクライアント側テクノロジーに依存しているため、許可されていない拡張機能からのアクセスを防ぐ試みを忘れる必要があります。これは、堅牢な認証/承認メカニズムの設計よりも、ワークステーションのセキュリティに関連しています。

  2. プラットフォームを設計するには、基本的に2つの方法があります。認証サービスのクエリを許可するようにAPIをインストルメント化することによって。または、トークンベースのアクセスを使用します。この場合、APIは、エミッターではなく、受信するすべてのリクエストで有効なトークンの存在をリクエストします。これは、認証サービスを新しい役割で拡張することを意味します。APIチケット発行者ですが、これはめったに興味深いことではありません。命題を読んでいると、セッショントークンをAPIに転送することで両方の世界をマージしているようです。これは間違っています。まず、これがCookieベースのセッショントークンが設計された理由ではありません。次に、APIに、ユーザー認証サービスのセッション管理システムとのある種のリアルタイム同期リンクの実装を強制します->簡単に回避できる結合。

  3. 主な目的は、許可されていないユーザーからAPIを保護することであり、ローカルシステムアクセスに依存する脅威に対処しようとはしないと想定します。

  4. ここで、APIに認証ロジックを実装しないことを考えると、ユーザーが認証サービスに対して認証するモデルに依存する必要があります。これにより、基盤となる拡張機能がアクセストークンを要求できるようになります。

  5. これにより、元のシナリオが次のように変更されます。

    • ユーザーはブラウザを使用してWebサイトにログインします。
    • Webサイトは、セッションキーを含むCookieを発行します。
    • これで、拡張機能はチケットリクエストを認証サービスに送信できます。リクエストにはセッショントークン（デフォルトのブラウザの動作）が含まれるため、認証されます。
    • 拡張機能がチケットを受信すると、拡張機能はそれをAPIに転送し、セッショントークンを要求します。
    • APIは、セッションマネージャーに問い合わせることによってチケットを検証します。セッションマネージャーが「はい、このチケットを作成しましたが、まだ有効です」と言った場合、APIはセッショントークンを生成し、それを拡張機能に返します。このトークンは、チケットではなく、後続のすべてのリクエストに挿入されます。これにより、セッションマネージャでの不要なワークロードが回避されます。
    • トークン（チケットと混同しないでください）の有効期間は数分など非常に短い場合があります->有効期限が切れた場合、拡張機能は認証サービスに戻り、新しいチケットを要求します（上記の手順3に戻ります）。

  6. 上記の解決策は、基本的に、チケットとトークンの両方がどれだけ安全であるかに依存しています。それらの設計は、少なくとも次の5つの残りの脅威に対する対策を実装する必要があります：i）チケット/トークンの推測の試み（安全-十分なランダム生成）、ii）チケット/トークンの計算の試み（十分なエントロピー）、iii）試みチケット/トークンを再利用する（有効期限）、iv）有効なチケット/トークンを改ざんしようとする（整合性チェック）、v）有効なトークン/チケットなしでAPIにアクセスしようとする（APIが受け取るすべてのリクエストでトークンを検証する） ）。

  7. このアプローチのもう1つの利点は、拡張機能固有のトークンを発行することでリソース割り当てを最適化できることです。これにより、APIで特定のロジックがトリガーされます（APIアクセスの削減、有効期間の短縮、リクエストの調整など）。

それが役に立てば幸い。

于 2012-02-07T00:45:10.057 に答える
2

つまり、example.comにWebサイトがあり、api.comにアクセスする必要があります。拡張機能は、ユーザーがexample.comにログインしていることを前提とし、セッションCookieを抽出し、それをapi.comに渡してOauthトークンを取得します。合理的に聞こえますが、ブラウザプラグインを作成しなくても簡単な方法があります。

あなたの場合、api.comはexample.comと通信して、セッションCookieを確認します。2つのシステムの間には強い依存関係があります。OAuthは通常、example.comとapi.comが相互に信頼しない場合に使用されます。

2つのシステムはすでに相互に何らかの信頼関係を持っているため、アーキテクチャを簡素化するためにさまざまなことを行うことができます。

  1. example.com/api/*でホストされるプロキシを作成して、セッションを検証してから、盲目的にapi.com/*に転送することができます。ブラウザに関する限り、クロスドメインリクエストはないため、すべてが正常に機能します。
  2. ドメイン間でフェデレーションログインを使用できます。これはプロキシ方式よりも複雑ですが、プラットフォームの既存の実装を簡単に見つけることができます。
于 2011-06-09T20:25:18.340 に答える