モバイルデバイスのログインシステムにJWTを使用する予定です。見つけることができるJWTトークンを更新するための実際の標準ワークフローはないため、以下のワークフローを作成しました。 JWTを使用する理由は、パフォーマンス上の理由によるものです。ユーザーが有効かどうかを確認する代わりに、JWTを信頼するすべてのリクエストに対してデータベース呼び出しを行います。
アプリに実装したいワークフローの提案があります。これは十分に安全ですか?効率的ですか?私が監督している明らかな問題はありますか?どのような合理的な改善を行うことができますか?
ユーザーは私のパスワードサービスにログインできます。ログインしたら、そのユーザーのすべてのデバイスを取得し、ユーザーは侵害されたデバイスを取り消すことができます。これが完了すると、JWTを更新する要求は、盗まれたトークンでは機能しなくなります。
もちろん、これはすべてSSLを介して行われます。
JWTトークンが盗まれた場合、攻撃者は被害者に基づいて電話をかけるのにX時間かかります。これはトークンの性質であり、リスクとして受け入れられていると思いますか?
JWTが盗まれた場合、デバイス名を含むHMACトークンもハイジャックされる可能性が高いため、被害者が自分のアカウントが侵害されていることを認識し、アクセスを取り消すまで、ユーザーはトークンを更新できます。これは受け入れられている習慣ですか?
何の領域で安全に受け入れられますか?
すべての無記名トークンの基本的なフローについて説明しました。トークンを所持する者は力を持っています。トークンが取り消されたかどうかを確認する条件がありますが、それはトークンが期限切れになるか取り消されるまで有効であることを意味します。これは、ユーザーがデータベースで有効かどうかを確認することと基本的に同じですが、ユーザーをデバイス+ JWTに置き換えます。それは問題ありませんが、パフォーマンスはそれほど向上しません。
他のシステムは2つのJWT(またはJWTと不透明トークン)を使用します。最初のJWTは、説明したように使用されるアクセストークンですが、失効をチェックしません。このトークンは非常に短命です-おそらく20分-> 1時間であり、それからかなり長く存続するリフレッシュトークンがあります。アクセストークンの有効期限が切れたら、更新トークンを送信し、更新トークンがまだ有効な場合は、新しいアクセストークンを発行します。更新トークンの有効期限が切れている場合は、認証を再度強制するか、新しいアクセスと更新トークンを発行するだけです。
ここでの値は、データベースに対して更新トークンを検証するだけでよく、アクセストークンの有効期限が切れたときにのみ検証する必要があるということです。ユーザーが更新トークンを失効としてマークした場合、更新トークンは攻撃者に新しいアクセストークンを取得しません。
トレードオフは、データベースへのクエリを頻繁に行わないことですが、アクセストークンが有効である限り、攻撃者は何でも実行できます。これは、非常に短いトークン(オッズのゲーム)を使用することで軽減されます。これが許容されるリスクかどうかは完全にあなた次第です。リスクを受け入れるかどうかは決定しません。 :)