6

私は現在、REST API を中心としたマルチプラットフォーム アプリケーションを設計しています (クライアントには、内部で開発されたモバイル アプリと、最初は AJAX の重い JavaScript クライアントが含まれます)。将来的には API がサードパーティに公開される可能性があるため、API での認証と承認に OAuth 2.0 を使用することを検討しています。

私は、特に JavaScript クライアントに関して、この取り決めに関するいくつかのセキュリティ問題を回避しようとしています。ほとんどの OAuth ドキュメントが焦点を当てているように見える、リダイレクトやポップアップなどを大量に使用して、このクライアントをサードパーティのクライアントのように動作させたくありません。私自身のドメインから配信されるため、webapp のサーバー側が実際のクライアントになり、クライアント シークレットとリフレッシュ トークンを保存し、javascript が必要に応じてサーバーから新しい認証トークンを取得できると考えています。

それを段階的な形式にするには：

  1. ユーザーは ajax 以外の HTML フォームを使用してログインし、サーバー側に保存される認証トークンと更新トークンを生成します。これにより、HTTP のみのログイン セッション Cookie が設定されます。
  2. ログイン後、javascript クライアント コードがユーザーのブラウザに送信されます。
  3. JavaScript クライアントは、独自のアプリケーション (REST API の一部ではない) の一部であるリソースにリクエストを送信し、トークンを取得します。セッション Cookie は、クライアントが本物であることを保証し、リファラーもチェックされます。認証トークンが返却されます。
  4. JavaScript クライアントは、REST API を使用してトークンを検証します。
  5. クライアントはトークンを使用して、有効期限が切れるまで REST API に対して要求を行うことができます。
  6. 認証トークンの有効期限が切れた場合、またはページが閉じられて再度開かれた場合、JavaScript クライアントは新しいトークンを要求できます。ログイン セッション Cookie がまだ有効である限り、webapp のサーバー側がトークンの更新を処理し、新しいトークンを送信します。

これは理にかなっていますか、それともシステムに大きな穴を残すでしょうか? 特に、設定されている Cookie に基づいて認証トークンを配布するリソースが Web 上にあるのは正気ではありませんか?

4

1 に答える 1

5

ブラウザへの通信が HTTPS であることを確認してください。これにより、途中でトークンが盗まれることはありません。そして、認証 Cookie に「セキュア」フラグを設定します。

  • 現在、ほとんどのブラウザー認証スキームは、Cookie で渡されるセッション トークンに要約されます。OAuth 2 スキームは、a) トークンが危険なユーザー情報を含まないダム トークン (である可能性がある) であり、b) 有効期限が切れているため、2 歩先を行っています。

  • （そのコメントをコンテキストに入れると、あるサイトからセッショントークンをポップして開き、自宅の住所と電話番号がそこにあることを発見しました.Ack!）

  • ブラウザの JavaScript 内でリクエストの HMAC 署名を行うコードを見たことがありますが、これには重大な免責事項が含まれていました。これを本番環境で使用しないでください。署名スキームでは、クライアント (javascript) が「秘密の」文字列を知る必要がありますが、ブラウザ/javascript は非常に安全ではないため、秘密の文字列を世界に渡すことになります。

しかし、すべての通信を HTTPS で行っている場合は、セッション トークンを Cookie として渡すおなじみのスキームに OAuth のひねりを加えているだけです。

于 2013-02-26T04:50:21.070 に答える