JWTでの短い有効期限の重要性
現在、ウェブサイトのAPIの認証にJSONウェブトークンを使用しています。永続的な取り消し可能な更新トークンを使用して更新される、1時間の短期間アクセストークンを使用します。
次に、アカウント+ログインシステムをWebサイトに追加し、それをAPIの使用状況に関連付けます。ただし、現在、これのセキュリティについて議論しています。
単純な実装は、セッションの3時間のアクセストークンであり、ユーザーが「ログインしたままにする」オプションを選択した場合、有効期限は2週間です。ただし、これにより、短い有効期限時間が役に立たなくなります。トークンが漏洩した場合、攻撃期間は2週間になります。
私たちが考えた代替案は、トークンが期限切れであるかどうかをチェックし、localstorage内のリフレッシュトークンまたはCookieとして自動的にリフレッシュする、ある種の「プロキシ」でしょう。
ナイーブバージョンは許容できる実装でしょうか、それともセキュリティリスクが高すぎますか？
これは、使用しているホストとネットワークの要件によって異なります。
JWT/Cookieなどのパスワードと同様に、アイテムを変更せずに使用できる期間が長いほど、ハッカーがそれを解読するのにかかる時間が長くなります。
私は個人的に、Webアプリケーションの起動時にランダムキーでJWTシークレットを生成しています。
JWTの寿命を5時間以内に設定しました。 OS、ブラウザ、IPアドレスなど、Cookie内の他のアイテムを探すこともできます。それはあなたがそれをどう扱いたいかによります。
すべてのJWTを営業時間の終わりに殺すこともできます。
ユーザーが「ログインしたままにする」オプションを選択した場合、セッションの3時間のアクセストークンと2週間の有効期限など。ただし、これにより、短い有効期限が役に立たなくなる可能性があります。
同意する。ユーザーにラストパスまたはキーパスの利用を奨励することもオプションの1つです。個人的には、5時間に1回ログインすることは不便ではなく、ビジネスを行うためのコストが安いと思っています。
これがあなたの質問に答えるか、助けになるかどうか私に知らせてください。
ステートフルセッションからトークンベースの認証への移行を検討するときにも、同様の懸念がありました。
既存の「最後のリクエストから20分」の有効性に似たシナリオが必要だったので、次のことに決めました。
ログイン時に、20分間有効なトークンを生成してユーザーに送信します。後続のリクエストでは、そのトークンを検証し、トークンが作成されてから5分以上経過している場合は、先に進んで新しい20分のトークンを作成し、それをユーザーに送信します。
これらのトークンには、2つのランダムなシークレットが暗号化されています。1つはアプリケーション用で、もう1つはユーザー用です（ユーザーレコードと一緒にデータベースに保存されます）。アプリケーション1はすべてのリクエストでチェックされ、ユーザー1はトークンの更新期限が来るたびに（最大5分ごとに）チェックされました。
ユーザーが懸念を抱いた場合、すべてのセッションをログアウトするか、パスワードを変更することができます。これらのアクションはどちらも新しいユーザーシークレットを生成します。つまり、多くても古いトークンは5分間のみ有効です。深刻な問題が発生した場合は、アプリケーションシークレットを変更して、既存のトークンをすべて直ちに無効にすることができます。