の構造とプロトコルさて、JWT はクライアント/サーバー通信のどこに当てはまるのでしょうか?
- これは認証とセッション クッキーを置き換えるためにありますか?
- これは、サーバーがセッション トークンをデータベースまたはメモリに保存する手間を軽減するためのものですか?
- クライアントが期待されるサーバーからデータを受信していることを確認するためのものであり、それが問題にならない場合は JWT は必要ありませんか?
- 接続が HTTPS/SSL の場合、サーバー間通信は必要ですか、それとも良い方法ですか?
ベストアンサー1
JWT とは何でしょうか?
これはサーバーだけが生成できるトークンであり、データのペイロードを含めることができます。
それは何の意味があるのですか?
JWTペイロードにはユーザーIDなどを含めることができるので、クライアントがJWTを送信したときに、あなた自身が発行したものであることを確認してください、 そして、次のことができます誰に発行されたかを確認します。
どこで役立ちますか?
通常、RESTful API、サーバーはいかなる種類のセッションも使用してはなりません。
セッションを使用する場合とどう違うのでしょうか?
典型的なセッションフローでは、ブラウザはトークンを含むクッキーを送信する、これはその後サーバーでマッチングサーバーが利用するデータユーザーを認証します。
JWTフローでは、トークン自体にデータが含まれています。サーバートークンをデコードしてユーザーのみを認証します。サーバーにデータは保存されていません。
JWT を使用した一般的な認証フローは何ですか?
- ユーザー認証情報が送信されました
/signin /signinJWT（キーで署名されたもの）を返します- JWTは以下に保存されます
localStorage - JWTはすべてのリクエスト（APIへの）で送信されます
- サーバーはJWTを読み取り、そこからユーザーIDを抽出できる。
Jwt には、algorithm.data.signature のエンコードされた形式が含まれているため、ユーザーがユーザー ID や jwt に保持されているその他のデータを操作しようとすると、jwt 署名は無効になります。
Jwt はエンコード（暗号化ではない）されているため、誰でも jwt のデータ コンポーネントを読み取ることができます（例については jwt.io を参照）。したがって、パスワードなどの秘密を jwt に保存しないことをお勧めします。
また、jwt を含む Web リクエストを行うときは、暗号化された接続 (SSL/TLS) を使用することをお勧めします。そうしないと、攻撃者が jwt を盗み、それを使用してユーザーになりすます可能性があります。