RESTful APIのためにJWTでステートレス認証を実装しようとしています。JWTが盗まれた場合はどうなりますか？
AFAIK、JWTは基本的に、REST呼び出し中にHTTPヘッダーとして渡される暗号化された文字列です。
しかし、どのような盗聴者があるかどう要求と盗塁トークンを参照してください？それから彼は私の身元を要求して偽装することができますか？
実際、この懸念はすべてトークンベースの認証に適用されます。
これを防止する方法は？ HTTPSのような安全なチャンネル？
私はかなりの深さで認証を処理するノードライブラリの作成者です。express-stormpathですので、ここでいくつかの情報を紹介します。
まず、JWTは通常NOTです。 JWTを暗号化する方法はありますが（参考：JWEs）、これは多くの理由で実際にあまり一般的ではありません。
次に、どのような形式の認証（JWTを使用するかどうかに関係なく）は、MitM攻撃（man-in-the-middle）攻撃の対象となります。これらの攻撃は、インターネット経由でリクエストを送信するときに攻撃者がネットワークトラフィックを表示できる場合に発生します。あなたのISPが見ることができるのは、NSAなどです。
これは、SSLがあなたのコンピュータからネットワークトラフィックを暗号化することで、認証時に一部のサーバーを暗号化し、ネットワークトラフィックを監視している第三者が何らかの形でサーバーのプライベートSSLキー（おそらく）のコピーを手に入れることができない限り、あなたのトークンやパスワードなどは表示されません。これが、すべての形式の認証でSSLが必須の理由です。
誰かがあなたのSSLを利用することができ、あなたのトークンを表示することが可能であること、しかし、のは、言ってみましょう：あなたの質問への答えはYESは、攻撃者はあなたを偽装するために、そのトークンを使用することができるということですあなたのサーバーにリクエストを行います。
は今、プロトコルが来る場所です。
JWTsは、認証トークンのひとつの標準です。彼らはほとんど何でも使うことができます。 JWTがすばらしいのは、追加の情報を埋め込むことができ、誰もそれを乱していないことを証明できることです（署名する）。
しかし、JWT自体は「セキュリティ」とは関係ありません。すべてのインテントと目的のために、JWTはAPIキーとほぼ同じです。ランダムな文字列を使用して、一部のサーバーに対して何らかの認証を行うことができます。
あなたの質問をより興味深くするものは、プロトコルが使用されています（おそらくOAuth2）。
OAuth2の仕組みは、クライアントに一時的な認証のためのTEMPORARYトークン（JWTのような！）を与えるように設計されていることです！
あなたのトークンが盗まれた場合、攻撃者はそれを短時間しか使用できないという考えがあります。
OAuth2では、ユーザー名/パスワードまたはAPIクレデンシャルを入力して交換することで、頻繁にサーバーを再認証する必要があります。
このプロセスはたびに行われるため、トークンが頻繁に変更されるため、攻撃者が大きなトラブルを起こすことなく常に偽装することが難しくなります。私はこれが古い質問ですけど^^
あなたはOAuthに言及しているので、関連する1つの質問：攻撃者がoauthトークンを盗み出してトークンをリフレッシュすると、理論的に私のAPIに永久にアクセスできます（トークンへのアクセスを取り消さない限り） – pratikm
通常、リフレッシュトークンには有効期限も設定されています（ただし、アクセストークンよりも長くなります）。しかし、はい、あなたは正しいです。 – rdegges
次の記事の著者は、JWTの欠点は、盗まれたJWTから回復する唯一の方法は、新しいキーペアを生成し、すべてのユーザーを効果的にログアウトすることだと主張しています。 DBに格納されたセッションIDの場合、Webサイトは影響を受けるユーザのセッションだけを削除し、すべてのデバイスからログアウトすることができます。ここでOAuth2がどのように画像に収まるか、あるいは提示された欠点を緩和するのに役立つかどうかはわかりません。 https://medium.com/@rahulgolwalkar/pros-and-cons-in-using-jwt-json-web-tokens-196ac6d41fb4 – Marcel
がうまくいけば、これは役立ちますが、私は、ここに私の$ 0.50ドロップすることができ、おそらく誰かが改善したり、完全に私のアプローチを拒否する引数を指定することができると思います。 HTTPS（ofc）よりRESTfulなAPIでJWTを使用しています。
短寿命トークンを発行する必要があります（ほとんどの場合、私のアプリでは実際にexpのクレームを30分に設定し、ttlを3日間に設定しています）限り、そのttlがまだ有効であるとトークンは、トークンを無効にするためには、はauthentication serviceについて）
をブラックリストに載っていないとして、私は、メモリ内キャッシュ層を使用したい（私の場合はRedisのを）いくつかの基準に応じてJWT blacklist/ban-listと表示されます。 （私はそれがRESTfulなph ilosophyが、私は彼らの残りの生存時間のためにブラックリストとして格納された文書は、本当に短命です - ttl claim-）注
：ブラックリストに載っトークンは自動的に更新することはできません
user.passwordまたはuser.emailが更新されている場合（パスワードの確認が必要な場合）、認証サービスは更新されたトークンを返し、前の証明書を無効にする（ブラックリストに登録する）ので、クライアントがユーザーの身元が何らかの形で侵害されたことを検出した場合、そのパスワード。 ブラックリストを使用したくない場合は（発行済み）のクレームをuser.updated_atフィールド（jwt.iat < user.updated_at、その後JWTが有効でない場合）に対して検証することはできますが、お勧めできません。最後に、誰もがそうであるようにトークンを正常に検証します。
注2：キャッシュのキーとしてトークン自体（実際は長い）を使用する代わりに、jtiクレームのUUIDトークンを生成して使用することをお勧めします。これは良いと私は思います（それはちょうど私の心の中で起きているので、確信していません）。あなたはsecure/non-http-onlyのクッキーを返し、jsを使ってX-XSRF-TOKENヘッダーを正しく実装することによって、CSRFトークンと同じUUIDを使うことができます。このようにして、CSRFチェック用のもう1つのトークンを作成する計算作業を回避できます。
あなたのアイデアを投稿するのは決して遅すぎません。お返事をありがとうございます。 – smwikipedia
トークンはしばしば短期間だけ有効です。また、データの機密性が懸念される場合はHTTPSを使用してください。 –
@JonathonReinhartしかし、トークンが間もなく期限切れになると、私のクライアントは時折自分自身を再認証して新しいトークンを取得する必要があります。それは面倒ではないですか？ – smwikipedia
@JonathonReinhartトークンが短命である理由を知ることができます。このように、サーバーはトークンの有効期限を追跡する必要がなく、したがってスケーラビリティのために道を譲ります。トークンの有効期限をより細かく制御することと、スケーラビリティを向上させることとの間のトレードオフのようなものです。 – smwikipedia