2017-03-07 17 views
0

人々は通常、JWTに権限を保存しますか?私はadmin: trueまたはscopes: ['add_foo', 'delete_foo', 'read_foo']の例を見てきました。これはうまくいくようですが、JWTは多くの権限/スコープがあれば大きなサイズになる可能性があります。 JWTが検証できるのであれば、ユーザー権限を得るためにDBやキャッシュを使用する必要がないので、本当に便利なようです。権限でのJWTの無効化

私の主な質問は、権限の変更があった場合にこれらがどのように無効にされるかです。

たとえば、sysadmin Joeは、ユーザーBobから 'add_foo'および 'delete_foo'権限を取り消しますが、 'read_foo'権限は保持します。このシナリオでは、ユーザーボブはトークンを完全に無効にする必要はなく、元に戻す必要があります。新しい権限を持つ新しいJWTを基本的に取得し、通常どおり実行する必要があります。

パスワード変更の際に新しいJWTを発行する例を見てきましたが、違いはsysadmin JoeがユーザーBobに更新を行う点です。したがって、このワークフローでは、ユーザBobが新しいトークンをすぐに取得する機会はありません。

ほとんどの例では、取り消されたトークンのブラックリストを維持したり、トークンが有効でなくなるようにDBレコードIDを変更したり、ユーザーごとの秘密を持って変更したりするための無効化を提案しています。

これらのすべてがトークンを取り消して無効であることをテストしますが、ユーザーはどのようにして新しいトークンを取得しますか?現在のJWTは現在無効ですか?それで何かしようとすると失敗するはずです。

私は "リフレッシュトークン"について言及しました。これらは広く使われていますか?ウェブ上で安全であるか、リフレッシュトークンを入手するのが難しいモバイルアプリに主に使用されますか?ブラウザのdevツールなどでリフレッシュトークンを盗むのはかなり簡単だと思われ、不正アクセスが検出されてリフレッシュトークンが取り消されるまで誰かがそのアカウントに永久にアクセスできます。

このシナリオでは、ユーザーBobに再認証を強いることは大したことではないでしょうか?許可はおそらくあまり頻繁に変更されません。

ありがとう、マイク。

答えて

0

有効期限を設定することができます(Webアプリの場合、通常はモバイルで15分から30分、モバイルでは1週間)。 を設定すると、クレームパラメータ( "iat")が発行されます。トークンを検証するたびに、トークンの「年齢」をチェックする必要があります。 5分以上経過している場合は、DBからデータをロードし、現在の値「iat」の新しいトークンを作成します。

0

権限が変更されると、このユーザーに対して発行されたトークンを無効にする必要があります。使用するさまざまなテクニックがあります。 Invalidating client side JWT session

ただし、JWTの主な利点の1つが失われるため、トークンの取り消しは推奨されません。サーバーストレージは必要ありません。

リフレッシュトークンの目的は、Oauth2.0で定義されているように、再認証

せずにアプリケーションが新しいアクセストークンを取得できるようにする更新トークンはアクセストークンを取得するために使用する資格情報ですされています。リフレッシュトークンは許可が頻繁に変更されない場合は、再する方が簡単な場合があり

、認証サーバによってクライアントに発行され、現在のアクセストークンが無効になるか期限切れになったときに新しいアクセストークンを取得するために使用されていますユーザーを認証し、変更が多い場合は、実際にトークンに含めるべきかどうかを検討してください。

関連する問題