[解決済み】JWTをブラウザに保存する場所は？CSRFから保護する方法は？

質問

Cookieを使った認証は知っています。SSLとHttpOnlyフラグを適用することで、MITMとXSSからCookieベースの認証を保護することができます。しかし、CSRFから保護するためには、より特別な手段を適用する必要があります。それらは少し複雑なだけです。( 参照 )

最近、JSON Web Token (JWT) が認証のソリューションとしてかなりホットであることを知りました。JWTのエンコード、デコード、ベリファイについては知っています。しかし、いくつかのウェブサイトやチュートリアルが、JWTを使用する場合はCSRF保護が必要ないと言っているのはなぜなのか理解できません。私はかなり多くの本を読み、以下に問題点をまとめようとしました。ただ、誰かにJWTの全体像を示してもらい、私がJWTについて誤解している概念を明確にしてもらいたいのです。

1. JWTがクッキーに格納されている場合、サーバーがクッキー/トークンを確認するためにセッションを持つ必要がないことを除けば、クッキーベースの認証と同じだと思います。特別な対策を講じなければ、CSRFのリスクは残ります。JWTはCookieに保存されていないのですか？

2. JWTがlocalStorage/sessionStorageに格納されている場合、クッキーは関係ないので、CSRFから保護する必要はないです。問題は、JWTをどのようにサーバーに送信するかです。私は以下を見つけました。 ここで jQueryを使って、ajaxリクエストのHTTPヘッダでJWTを送信することが提案されています。つまり、ajaxリクエストだけが認証を行うことができるのでしょうか？

3. また、もう一つ ブログ には、JWTを送信するために"Authorization header"と"Bearer"を使用することが示されています。そのブログで語られている方法がよくわかりません。どなたか、"Authorization header"と"Bearer"について詳しく説明していただけませんか？これは、すべてのリクエストのHTTPヘッダでJWTを送信するようになるのでしょうか？もしそうなら、CSRFはどうなるのでしょうか？

解決方法は？

JWTトークンは、以下のような新しい認証・認可プロトコルでデフォルトのトークン形式として使用されているため、人気があります。 OAuth 2.0 と OpenIDコネクト .

トークンがクッキーに保存されている場合、ブラウザは同じドメインへのリクエストごとに自動的にトークンを送信するため、やはりCSRF攻撃に対して脆弱になります。

ベアラ認証は 認証スキーム HTTPで定義されています。基本的には、以下のことを意味します。 ユー は、リクエストの Authorization HTTP ヘッダーに (JWT) トークンを貼り付けます。ブラウザは NOT が自動的に行うので、ウェブサイトの保護には適しません。ブラウザが自動的にリクエストにヘッダを追加しないので、認証情報が自動的にオリジナルドメインに送信されることに依存するCSRF攻撃には脆弱ではありません。

ベアラ方式は、AJAXコールやモバイルクライアントから消費されるウェブAPI（RESTサービス）を保護するためによく使われます。