認証あれこれ疑問雑記
Q. SPAでトークン認証する場合、AccessTokenとRefleshTokenってどう扱うよ?
AccessTokenは取りやすい場所に置いておけばいい。
RefleshTokenはXSS対策として取りにくい場所(Cookie, Web Workerなど)に置いておけばいい。
事例①:Auth0 フロントSDK
リフレッシュトークンをWeb Workerに保存してる
アクセストークンはLocalStorage(or in-memory)に保存してる
認証トークンの管理方法によって変わるのは、ユーザーがXSSを踏んだタイミングでの攻撃に加えて、このタイミングで認証トークンを奪取されるリスクとなる。認証トークンを奪取されることで追加の攻撃が可能となる。(実際にはこのリスクを受容できるシステムは多いはず。)
ここ大事なところで、盗まれたところで大きなリスクじゃなくね?ていうアプリは、LocalStorageでも良いんじゃない?て思ったりする。
だって、パスワードとかが盗まれるわけじゃ無いやん。
敢えて認証トークンの管理方法の安全性比較すると Cookie (httpOnly) > Closure or Web Workerへの分離 >> 単純な変数での保持 = Local Storage というのが私の考えとなる。
なるほど、Closure、Web Workerてのに切り出すと、よりセキュリティが強くなるんかぁ
ただ、この方法は実装が複雑になりそうやな...onigiri.w2.icon
Auth0 SPA SDKの実装は興味深く、漏洩時の影響が大きいリフレッシュトークンを扱う処理をWeb Workerに分離するアプローチを採っている。(リフレッシュトークンに関する処理はSDK利用者が意識する必要がないため、SDKで隠蔽しやすいということもある。)
おおおお!!!onigiri.w2.icon
リフレッシュトークンは、どうにかしてCookieに保存すると思ってたけど、そういうことじゃ無いんかww
結論では、BFFを構築してバックエンドに保管とするのが最良で、Web Worker、Closure + 外部関数のコピー保持(適用が困難な場合もある)でXSSが入り込むコンテキストから分離することも有効としている。
BFFを構築するってどういう感じなんやろ???onigiri.w2.icon
Auth0のSPAライブラリはリフレッシュトークンを使ったアクセストークン再発行処理をWeb Workerに隔離することで、XSSに対してもアクセストークンの取得はできても、リフレッシュトークンは取得できない仕組みになっているとのこと。
なるほどなぁ...onigiri.w2.icon
これはもう、IDDaSにSDKとかも頼った方がいいなぁwwww
現時点ではトークンを完全に安全に保存できるブラウザAPIはないとして、バックエンドがある場合にはトークンをサーバーサイドで管理すべきとしている。バックエンドがない場合はできる限り安全に扱うこと、という記載となっており、具体的な実装には踏み込んでいない。
なるほどなぁ........onigiri.w2.icon
バックエンドでトークンを管理するの意味がいまいちよく分からんけど
Local StorageはJavaScriptから自由にアクセスができるため、XSS脆弱性があると中身を取得されてしまう。(利用しているサードパーティーのライブラリに脆弱性がある場合も同様。)
このため、httpOnly + secure + SameSite=strictなCookieに、暗号化+署名をして保存するのがベストプラクティスである、という主張となっている。
これやるとなるとさ...やっぱりBFFとか使うことになるんかな?
これやと同一ポリシーの壁を越えられへんクネ?