私はこのブログ投稿 ( https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/ ) をフォローしており、JWT の側面について混乱しています。
上記の投稿は、Cookie として保存されている JWT があるかどうかを確認することで、ユーザーが既にログインしているかどうかをテストしているようです。ある場合は、それをデコードしてユーザー名やその他の情報を見つけ、ユーザーを認証された場所にリダイレクトします。ページ。
誰かが偽の JWT Cookie を追加して、アプリの認証された部分にアクセスするのを妨げているのは何ですか? 明らかな何かが欠けているに違いありません。言い換えれば、セッションを維持するとき、フロントエンドは、JWT が「サーバーによって署名された」ものであり、アクセスを試みるために不正に作成されたものではないことをどのように保証するのでしょうか?
多くのアプリでは、誰かが偽の JWT を追加して、ログインしている場合にのみ表示したいフロント エンドの部分にアクセスすることができます。同じことをするコード。
バックエンド サーバーは、フロント エンドに存在してはならないキーを使用して JWT をエンコードしました。JWT をサーバーに戻すと、サーバーはリクエストを処理する前にそれをデコードします。したがって、誰かがあなたのログイン資格情報を以前に使用したこと、応答として JWT を送信したこと、および誰かが再度 JWT を送信したことを認識します。これにより、(実際の) JWT を持たない人々による API への攻撃がブロックされます。
また、サーバー側でステートレスであり、攻撃者がサイトにリクエストを埋め込むことができず、ブラウザーがセッションを追加することを信頼できないため、従来のブラウザーで特定のクロスサイト リクエスト フォージェリ攻撃をより困難にするという点で、セッション cookie よりも利点があります。クッキー。
しかし、それはより大きなセキュリティ ソリューションの一部にすぎません。