JWT認証および許可スキーマ
私はOauth2ドキュメントを調べていて、それが一種の寛容なセキュリティであると思ったので、Web APIと通信するモバイルアプリの画像のような特別なスキームでJWTトークンを実装しようとしました。
注：Oauth2リフレッシュトークンのアイデアは、盗まれて（合法的および悪意のあるユーザーによる）並列使用を許可する可能性があるため、それらを回転させて（各リクエストでリフレッシュトークンをリフレッシュする）盗難検出を実装しない限り、なぜ使用しないのですか？
認証フローの仕組み：
- ユーザーが資格情報でログインすると、有効期間は20分のjwtになります。
- 有効期限が切れると、jwtは、それがブラックリストに登録されているか（再ログイン）、新しいトークンの生成に使用されたかどうかをチェックするdbチェックをヒットすることによって更新されます。
- 更新に使用されなかった場合は、受け入れられ、低グレードのアクセストークンの発行に使用されます。
- トークンが以前に使用された場合、またはその親とは異なるクライアント+デバイス+ユーザーが資格情報チェック（パスワードまたはロック画面コード）を提供した場合
- 合格した場合、このチェックは、新しい最初のユーザーログインのように、db上のすべての親と子をブラックリストに登録する新しい1年生のトークンを発行します。
- ロック画面が失敗すると、ユーザーにログイン画面が表示されます。
質問は次のとおりです。
- 可能なセキュリティホールは何ですか？ （私は2つの使用例を見つけました：盗まれた有効なアクセストークンは20分持続しますOauthトークンと同じ問題です。ここで損失はありません。そして盗まれたスリープトークン：ユーザーはたとえば7日間ログインしていません、トークンユーザーが再度ログインするか、3か月の永続性-私たちのポリシー-の後にトークンチェーンが取り消されるまで、盗まれて使用されます。この盗難は、ユーザーがアプリで行う最後のリクエストでトークンを傍受する必要があるため、Oauth2の更新を盗むよりもスリムです。トークン）
- このスキームで攻撃者がアプリで発生する可能性があるユーザーエクスペリエンスの問題は何ですか？
![jwt token flow]()
@jpodwysがコメントで述べているように、HTTPSは安全なトランジットです。攻撃者がOAuth2更新トークンを盗み、他の重要な情報を盗むことはないと私には考えられません。つまり、HTTPS接続を介してトークンが盗まれるまでに、あなたはすでにpwnされており、ゲームオーバーです。 OAuth2は十分にテストされたプロトコルであり、多くの言語で多くのテスト済みの実装があります。自分で設計および実装することを選択したものよりも安全であると強く思います。一般的に、自分でロールするのは間違いです。理由については これらすべての回答 を参照してください。
リフレッシュトークンが存在する理由についての質問に答えると、リフレッシュトークンは、盗まれたリフレッシュトークンを処理するのではなく、ユーザーが認証を取り消すことができるように存在します（事実上、決して発生しません）。ユーザーがアクセスを許可し、後で突然それを取り消す場合を考えてみましょう。発生した失効から有効な失効までの遅延を最小限に抑える必要があります。遅延を（ほぼ）ゼロにする1つの方法は、すべての呼び出しでサービスプロバイダーに確認することです。ただし、すべてのリクエストでSP=を使用してチェックすることはパフォーマンスが良くありません。代わりに、アクセストークンを限られた期間使用することを許可し、時々それを強制的に更新するようにします。これはつまり、ユーザーが認証を取り消すと、アクセストークンの有効期間よりも短い時間で有効になります。