WebアプリケーションでのJSON Webトークンとスライド式の有効期限

Webアプリケーションでは、これまでで最も一般的な認証方法はCookieの使用でした。CookieにはサーバーセッションIDが保存され、独自の有効期限があります。 同時に、ユーザーが次回サーバーにアクセスしたときに、この日付を自動的に更新することができます。 このアプローチは、スライド式有効期限と呼ばれます。



ただし、最近、開発者はさまざまな理由でCookieとサーバーセッションの使用を拒否しようとしており、代替の認証方法を探しています。 その1つは、JSON Web Token（JWT）の使用です。これは、認証と承認に必要なすべての最小限の情報を暗号化された形式で含むトークンです。 同時に、マーカーは自己完結型であるため、セッションにユーザーデータを保存する必要はありません。 ただし、これにより、JWTの制御に特定の困難が追加され、Cookieに対するすべての利点が無効になります。 インターネット上で、これらの問題に対するいくつかの解決策を見つけました。ここでは、そのシンプルさで多くのプロジェクトのニーズを満たす代替オプションを提供したいと思います。



私の意見では、開発者がクッキーとセッションを拒否できる主な理由は次のとおりです。

• 開発者はますます、単一ページWebアプリケーション（SPA）に切り替えて、APIを介してサーバーにアクセスしています。 同じAPIを使用して、モバイルアプリケーションを提供します。 また、認証アプローチを統一するために、モバイルプラットフォームでのCookieの使用は難しいため、アクセストークンの使用を好みます。
• Webアプリケーションが水平方向にスケーリングされると（Webファーム）、サーバー間でセッション状態を同期するという問題が発生します。 もちろんこれには解決策がありますが、セッションをまったく使用する必要のないステートレスアプリケーションを作成する方が簡単です。 JWTはこの問題を解決します。

JWT自体には、Cookieと同様に、独自の有効期限があり、最も単純な場合は次のように使用されます。

1. ユーザーは、ユーザー名とパスワードを送信することにより、サーバー（および一般的には承認サーバー）からのアクセスを要求します。
2. 承認サーバーはユーザーの有効性を確認し、特定の有効期限（たとえば、2週間後）を持つアクセストークンをユーザーに送信します。
3. ユーザーはこのアクセストークンを使用して、サーバー（および通常はリソースサーバー）上のリソースにアクセスします。
4. 有効期限（2週間後）に、ユーザーは認証手順を再度実行する必要があります。

このアプローチの主な欠点は、有効期限が短い場合、ユーザーがユーザー名とパスワードを入力する必要があることです（これは、パスワードの頻繁な転送に関して不便で安全性が低い）。 または、単純に長い有効期限（たとえば、1年）を使用することをお勧めします。 ただし、このアプローチでは多くの問題が発生します。

• アクセストークンが盗まれた場合（XSSの脆弱性などを介して）、攻撃者は長期間リソースにアクセスする可能性があります。
• 管理者がユーザーの権利を制限したり、役割を変更したい場合は、アクセストークンが更新されるように、ユーザーは再度認証手順を実行する必要があります。

前述の問題を解決するために、短期アクセストークンとともに、2番目の長時間実行リフレッシュトークンを追加で使用することがしばしば提案されます。 同時に、認証中に、ユーザーは更新トークン（有効期限が1年など）とアクセストークン（30分など）を受け取ります。 また、リソースへのアクセスには引き続きアクセストークンを使用しますが、新しいアクセストークンを取得するために30分後、彼はリフレッシュトークンを承認サーバーに送信するだけで、応答して新しいアクセストークンを送信します。ユーザー権限。



更新トークンアプローチは、クライアントコードとサーバーコードの両方をかなり複雑にします。 同時に、ユーザーのすべての更新トークンとクライアントIDおよびその他の追加情報を保存する必要があります。



ユーザーがログイン後にリソースを無限に使用するようにしたい場合は、トークンにスライド式の有効期限を実装することをお勧めします。 つまり、最も単純な（最初の）場合、アクセストークンを受信すると、サーバーは有効期限（またはその都度）に近づくと、日付がシフトされた新しいアクセストークンをユーザーに送信します。 トークンの盗難が発生した場合のこのようなアプローチは、攻撃者が無限にリソースを使用できるという事実につながります。



2番目の場合、同じことが行われますが、更新トークンに対してのみです。



実際に私が見つけたアプローチはすべてここにあります。 次に、簡単にするためにアクセストークンを1つだけに制限しますが、同時に有効期限がスライドし、盗難の場合にアクセス許可を変更し、アクセストークンを制限することができます。



これを行うには、新しいRefreshDateフィールドをトークンに追加します（トークンを更新する必要がある日付。指定した場合、有効期限よりも短くする必要があります）。データベースのユーザーテーブルにはMinRefreshDateというフィールドが1つしかありません。 このフィールドには、ユーザーに有効なRefreshDateの最小日付を格納する必要があります。 トークンを更新するには、MinRefreshDateが空ではなく、更新する必要のあるトークン自体のRefreshDateよりも常に小さい必要があります。



この場合、使用プロセスは次のようになります。

1. 今日が1789年1月1日だとしましょう。 更新間隔は3日間です。 MinRefreshDateはユーザーに指定されていません（NULL）。
2. ユーザーが初めてログイン/パスワードを承認サーバーに送信し、応答として、RefreshDate = 01/04/89のアクセストークンを受信します。 同時に、サーバーはMinRefreshDateが空であることを認識し、01/04/89に等しくします。
3. ユーザーは、1月1、2、3日にアクセストークンを使用して、リソースサーバーにアクセスします。
4. 管理者は1月2日にユーザーロールを変更します。
5. 1月4日（またはそれ以降）の次のユーザー要求で、リソースサーバーはアクセストークンを更新する必要があることを認識し、それ自体が承認サーバーに要求します。
6. 承認サーバーは、MinRefreshDateが空ではなく、トークンのRefreshDateよりも小さいことを確認し、現在のユーザー権限を確認して、RefreshDate = 01/07/89および新しいユーザーロールを持つ新しいアクセストークンを生成します。
7. リソースサーバーは、ユーザーに新しいアクセストークンとリソースを渡します。
8. ユーザーは、新しい役割の下で1月4日と5日に新しいアクセストークンを使用し続けます。
9. 6日、アクセストークンが攻撃者に盗まれました。 ただし、ユーザーはこれに気付きます（たとえば、自分のプロファイルが通常のIPまたはブラウザーからアクセスされなかったという通知を受け取った場合）
10. 同じ日に、ユーザーはプロファイル設定を入力し、「すべてのセッションを閉じて終了する」などをクリックします。 これにより、このユーザーのMinRefreshDateがリセットされます。
11. 7日に、攻撃者は盗まれたトークンを更新しようとしますが、MinRefreshDate = NULLであるため更新できません。
12. 8日、ユーザーは再度認証手順を実行し、ログイン/パスワードを送信します。 同時に、RefreshDate = 11.01.89の新しいトークンを受け取ります。 同時に、サーバーはMinRefreshDateが空であることを確認し、01/11/89に等しくします（すでに日付が入力されている場合は、そうではありません）
13. 9日、攻撃者はトークン（RefreshDate = 01/07/89）を再度更新しようとしますが、RefreshDateがMinRefreshDateよりも小さいため更新できません。

それがソリューション全体です。 盗まれたロールまたはトークン更新ロールのRefreshDateが発生するまで、時間枠に関連する問題がまだあります。 また、ユーザーがトークンが盗まれたことに気付かない場合、攻撃者はトークンを安全に更新し、ユーザーに代わってリソースを使用することができます。 ただし、これらの問題はすべて、更新期間（たとえば最大30分）を短縮し、異常なユーザーアクティビティに対する制御を強化することで部分的に解決できます。



このアプローチが誰かに興味を持ち、実際に適用されるという幻想はありませんが、実際の使用にどれほど安全で適切であるかについて意見を聞きたいと思います。



PS：もちろん、実際のプロジェクトでは、SSLと同期トークン（偽造防止トークン）を使用して追加のセキュリティを提供する必要があります。 さらに、MinRefreshDateの代わりに、一意の文字シーケンス（SessionTokenなど）を使用できます。 ただし、この場合、JWTはSessionTokenフィールドを追加して、検証できるようにする必要があります。 特定のトークンをより柔軟に制御および制限するために、各ユーザーに対してSessionToken-sのセット（各認証中に作成される）を保存することもできます。



ありがとう