Auth0のアクセストークンをLocal Storageに保存するのは安全？メリット・デメリットをin-memory方式と比較して検討する - Flatt Security Blog

※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部

[uhavetwocows]

書きました! => 続編で、実際にやってみた話も書きました！ https://blog.flatt.tech/entry/auth0_access_token_poc

[efcl]

in-memoryといっても同じプロセスならglobalを変更すればどうにでもなってしまう。 なので、primordialsでのfreeze、Shadow Realm、process isolationとかのグラデーションがある気はする。

[sonots]

:eyes:

[gfx]

"Auth0のドキュメントではin-memory方式を推奨していますが（…）利便性とサービス側のユースケースに応じてどちらを採用しても良い程度の差だと感じました"

[deejayroka]

“このように、Auth0のドキュメントではin-memory方式を推奨していますが、筆者が検討した限り、どちらの方法においてもフロントエンドでアクセストークンを直接扱う以上、アクセストークンを完全に保護することは難しく

[azzr]

Auth0って、自社プロダクトを推すためにセキュリティ的に間違ったことを書いているから信用したくない。

[seal2501]

最近、localStorageでもいいよね派が増えてきて嬉しい。本気でセキュアにしたいならBFF sessionでやるしかないので、その労力に見合ってるかで判断する

[sp_ice]

Auth0に倣ってin-memory方式で自前の認証実装したことあったが、ブラウザリロードしたら消えちゃうし使い勝手悪すぎた。 確かにin-memoryでも完全に読み出し不可にできるわけではないんだから、Local Storageに保存で良かったの

[dorapon2000]

“このように、Auth0のドキュメントではin-memory方式を推奨していますが、筆者が検討した限り、（略）利便性とサービス側のユースケースに応じてどちらを採用しても良い程度の差だと感じました。”

[agektmr]

関連してこの記事が大変勉強になりました https://mizumotok.hatenablog.jp/entry/2021/08/04/114431

[aox]

紙のメモに書いておけば良いのでは

[muuran16]

AzureADのmsal-browserはlocalStorageに置かないとSLO（フロントチャネルのみ）が出来なかった気がする。