SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトーク

SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は

[trace22]

“SameSite=Strictだけでは完全なCSRF対策にはならない”なんか、コレ書かない人ちらほら見る気がする

[yojik]

“以上から、IDトークンの保存場所はどちらでもよく、なんならlocalStorageでも構いません。”

[circled]

LaravelみたいにPOSTリクエスト実行しようとすると「いや、お前CSRF対策してないんで許されないから？」と初心者に丁寧にダメ出ししてくれるフレームワーク増えたので、昔よりも危険性は年々下がってる

[pmint]

個人情報のほうのトークン。IDプロバイダーから何度でも取得できるので、保存はキャッシュ。つまり、不要。アクセストークンのことなら、セッションキーと同等。セキュリティだけ考えてると、こうなっちゃうのかな。

[Shinwiki]

自分で考えるの面倒くさいから「こっち」って指定してくれよっていう質問意図でしょ。決定の根拠を求めてるっつーか「あの人もこう言ってるから」で安心したいのか客を説得したいのかは知らんが

[akymrk]

“保存場所はどちらでもよく、なんならlocalStorageでも構いません。ただ、微妙なところで差があることも確か”"サーバーに保存するためには、キーとなる値が必要で、それは結局CookieかlocalStorageに保存するしかありません"

[wdoomer]

メンテされてるフレームワークを使うのが最適解なのかな、と思う所ある

[meonal]

セッションvsJWTの話か。セッション使う場合IDトークンは検証後はサーバーに保存する必要って特にないよね？