私は現在、REST API を中心としたマルチプラットフォーム アプリケーションを設計しています (クライアントには、内部で開発されたモバイル アプリと、最初は AJAX の重い JavaScript クライアントが含まれます)。将来的には API がサードパーティに公開される可能性があるため、API での認証と承認に OAuth 2.0 を使用することを検討しています。
私は、特に JavaScript クライアントに関して、この取り決めに関するいくつかのセキュリティ問題を回避しようとしています。ほとんどの OAuth ドキュメントが焦点を当てているように見える、リダイレクトやポップアップなどを大量に使用して、このクライアントをサードパーティのクライアントのように動作させたくありません。私自身のドメインから配信されるため、webapp のサーバー側が実際のクライアントになり、クライアント シークレットとリフレッシュ トークンを保存し、javascript が必要に応じてサーバーから新しい認証トークンを取得できると考えています。
それを段階的な形式にするには:
- ユーザーは ajax 以外の HTML フォームを使用してログインし、サーバー側に保存される認証トークンと更新トークンを生成します。これにより、HTTP のみのログイン セッション Cookie が設定されます。
- ログイン後、javascript クライアント コードがユーザーのブラウザに送信されます。
- JavaScript クライアントは、独自のアプリケーション (REST API の一部ではない) の一部であるリソースにリクエストを送信し、トークンを取得します。セッション Cookie は、クライアントが本物であることを保証し、リファラーもチェックされます。認証トークンが返却されます。
- JavaScript クライアントは、REST API を使用してトークンを検証します。
- クライアントはトークンを使用して、有効期限が切れるまで REST API に対して要求を行うことができます。
- 認証トークンの有効期限が切れた場合、またはページが閉じられて再度開かれた場合、JavaScript クライアントは新しいトークンを要求できます。ログイン セッション Cookie がまだ有効である限り、webapp のサーバー側がトークンの更新を処理し、新しいトークンを送信します。
これは理にかなっていますか、それともシステムに大きな穴を残すでしょうか? 特に、設定されている Cookie に基づいて認証トークンを配布するリソースが Web 上にあるのは正気ではありませんか?