REST API？
単一ページアプリケーションのバックエンドとして使用しているREST APIをセキュリティで保護しようとしています。このAPIは、管理者が管理する一連の権限。私が考えているのは次のとおりです。
- すべての接続はHTTPSを介する必要があります。プレーンHTTPリクエストはHTTPSにリダイレクトされます。
- ユーザーはユーザーが作成したユーザー名とパスワードを持っています。
- クライアントはユーザー名/パスワードを
/loginルートに送信します。そのユーザーの有効なパスワードである場合、サーバーは有効期間が短いアクセストークンと有効期間が長い更新トークンを返します。- アクセストークンは、ユーザーを識別し、有効期限がある署名付きJWTです。
- 更新トークンは、データベーステーブルの行に対応するGUIDになります。この行にはユーザーIDが格納されます
- 保護されたルート（
/loginを除くすべて）にアクセスする場合、アクセストークンが必要になります。サーバーは署名を検証し、有効な場合は有効期限を確認します。トークンの有効期限が切れていない場合、ユーザーIDは認証ロジックのサーバー側コードで使用できるようになります。 - アクセストークンの有効期限が切れている場合、クライアントは自動的に更新トークンを
/refreshエンドポイントに送信して、新しいアクセストークンを要求します。サーバーはデータベースをチェックします。対応する行がまだ存在する場合、新しいアクセストークンがクライアントに返されます。
このスキームは安全に聞こえますか？
はい！警告の先制者、まず第一に、私はインターネットの乱暴者です。これ、YMMVなどから決定しないでください。
それが邪魔にならないので、これは私にはかなりうまく見えます。ここでは異常なことは何もないようです。チェックする主なことは、/refreshなどのセカンダリエンドポイントを保護することです。たとえば、いじられないようにしてください。そして、これらすべてをテストスイートで徹底的にテストしてください。
一般的な経験則は、「自分のセキュリティをロールバックしないこと」です。
最初に、パスワード、有効期間の短いアクセスJWT、有効期間の長いリフレッシュトークンを使用するセキュリティスキームが良い方法であるかどうかという主な質問に答えます。まあ、それは実装次第です。存続期間の長い更新トークンを持つことは良い考えのように思えるかもしれませんが、そうではありません。これをよりよく理解するために、攻撃者が更新トークンを取得するシナリオを考えてみましょう。これで、攻撃者は、特定の更新トークンがデータベースで無効化されなくなるまで、そのユーザーアカウントにアクセスし続けることができます。
ITEF RFC 6749 と ITEF RFC 6819 を確認すると、更新トークンを1回だけ使用する必要がある理由と、更新トークンのローテーションが必要な理由がわかります。まあ、良い知らせです。ドキュメント全体を実際に読む必要はありません。このドキュメントからの重要な引用は次のとおりです。
「認証サーバーは、すべてのアクセストークンリフレッシュ応答で新しいリフレッシュトークンが発行されるリフレッシュトークンローテーションを使用できます。以前の更新トークンは無効になりますが、承認サーバーによって保持されます。更新トークンが危険にさらされ、その後攻撃者と正当なクライアントの両方で使用された場合、そのうちの1つが無効化された更新トークンを提示し、認証サーバーに違反を通知します。」
さて、更新トークンが1回だけ使用され、正しくローテーションされることを保証できる正しい動作ソリューションを持つことは、トリッキーで複雑です。トランジット中にリフレッシュトークンが失われる可能性があるシナリオも、処理が容易ではありません。 SuperTokensは、使用のたびに更新トークンをローテーションするだけでなく、トークンの盗難シナリオ、つまり誰かが更新トークンを盗んだ場合の特定にも役立つ完璧なソリューションを見つけました。
もちろん、このソリューションは、XSS、CSRFなどのセッション関連のさまざまな攻撃の防止にも対応しています。