web-dev-qa-db-ja.com

侵害されたJSON Web Token（JWT）Bearer Token

認証と承認を必要とするRESTサービスを実装しています。REST APIのステートレスな性質のため、JWTを使用して、トークンによるAPI。API呼び出しごとにデータベースにアクセスする必要はありません。

JWTを評価した後、いくつか質問がありました。

  1. クライアントとサーバー間で共有されるセキュリティが侵害されたトークンシークレットの状況をどのように処理しますか？
  2. すべてのクライアントをログアウトし、将来のリクエストのために新しいトークンシークレットを定義しますか？ （それは悪い経験になるでしょう）
  3. 侵害されたクライアントをログアウトする方法はありますか？

背景の詳細​​：iOSアプリとNode.jsバックエンドの間でそのフローを使用します。

authenticationoauthrestjson
20
BausNauf

あなたの質問に答えるには：

1）クライアントとサーバー間で共有されるトークンの秘密が危険にさらされている状況にどのように対処しますか？

トークンに有効期限を追加します。有効期限が切れた後は、トークンを使用できないことを確認してください。しかし、これはトークンの有効期限内の不正アクセスを防止しません。

したがって、この問題を克服するために、クライアントのIPアドレスまたは他のそのような情報をトークン内に埋め込むことができます。また、トークンを含む受信リクエストが、発行先と同じIPアドレスから使用されていることを確認してください。

2）すべてのクライアントをログアウトし、将来のリクエストのために新しいトークンシークレットを定義しますか？ （それは悪い経験になるでしょう）

許可された方法で複数のトークンを使用しているすべてのクライアントをログアウトする場合は、いいえ。トークンの有効期限が有限であれば、同時に複数のトークンを引き続き使用できます。これにより、意図した時間枠内でトークンが使用されるようになります。

しかし、もしトークンが盗まれた時のことで、どういうわけかそれを見つけたとしたら。そのユーザーに対するすべてのトークンを無効にすることをお勧めします。

ただし、特別な場合にすべてのトークンを明示的に取り消すメカニズムが必要になる場合があります。ユーザーが自分のパスワードが危険にさらされている可能性があると考えているために、ユーザーが自分のパスワードをリセットしたときのようになります。

）侵害されたクライアントをログアウトする方法はありますか？

おそらく、侵害されたトークンを正確に特定する能力に依存します。これにより、すべてのクライアントがそのトークンを使用してアクセスできなくなる可能性があります。しかし、私はそれをお勧めしません。ただし、古いクライアントがトークンを使用できなくなったときに、動的に再認証して新しいアクセストークンを取得するコードをいつでも記述できます。 :-)

必要に応じてトークンを無効にすることを恐れないでください。トークンを紛失した場合は、動的スクリプトを記述して再認証します。新しいトークンを使用するときにセッションの詳細が失われる可能性があると思われる場合は、再認証中に期限切れのトークンをサーバーに再送信してください。この期限切れのトークンを使用すると、古いトークンのセッションの詳細で新しいトークンを再構築できます。期限切れのトークンにセッションの詳細が埋め込まれている場合。

15
Hari Krishna Ganji

以前に付与されたトークンを有効期限前に取り消すことができるようにする場合（有効なセキュリティ上の懸念事項）、データベースルックアップを含める必要があります。これにより、JWTの主な利点の1つが無効になるため、しないようにすることができます。そもそもそれらを使用してください。

このケースについて説明する記事は次のとおりです。 https://www.dinochiesa.net/?p=1388

6
Ian Storm Taylor

私の場合、データベースにもトークンを保存しています。

enter image description here

初期認証中に、ユーザーはユーザー名とパスワードを送信します。資格情報が検証され、データベースにも格納されるトークンが生成され、クライアントにもトークンが送信されます。すべてのクライアント要求で、データベースにそのユーザーのトークンが存在するかどうかも確認します。

クライアントがログアウトしてトークンを取り消したい場合は、単純にIDテーブルからトークンを削除します。

2
sonam

JWTトークンをデコードして、すべての情報をjson形式として読み取ることができます。次に例を示します。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

最初の部分はヘッダーです：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

{
  "alg": "HS256",
  "typ": "JWT"
}

2番目の部分はペイロードです：eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

最後の部分は、次のように作成された署名です。

//In our example, the algorithm is (HS256)
signature = algorithm(hash of (header + payload), secret)

さて、その鍵はトークンの署名の中にのみ隠されていたので、次の結論に達しました。

  1. KEYは安全な場所に保管し、誰にも公開しないでください。
  2. 認証にJWTトークンを使用する場合は、SSL/TLSを介して使用する必要があります。
  3. JWTトークンは、秘密鍵によるsignature検証なしでは信頼されません。
  4. JWTで使用される情報の署名のみを行う場合に備えて、JWTトークンのISSUERは、機密情報をJWTトークン内に配置してはなりません。

アカジャ

1）クライアントとサーバー間で共有されているトークンシークレットが危険にさらされている状況にどう対処しますか？

sSL/TLS（セキュア接続）を使用し、ログインシステムに応じて各トークンを期限切れにします。ユーザーがログインするたびにJWTトークンを作成してJWTトークンを作成する必要があります。

2）すべてのクライアントをログアウトし、将来のリクエストのために新しいトークンシークレットを定義していますか？ （それは悪い経験になるでしょう）

秘密鍵が危険にさらされた場合、新しい秘密鍵を確実に作成し、ログアウトを発行してアクティブなセッションを更新し、システムにすべてのアクティブなユーザーを強制的に再認証させる必要があります。

1
Akam