Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SPAでの認証方法に関するマサカリぶん投げ会場はこちらです
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
defunty
September 16, 2021
Programming
1.1k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
SPAでの認証方法に関するマサカリぶん投げ会場はこちらです
LT資料(2021/9/16)
defunty
September 16, 2021
More Decks by defunty
See All by defunty
プライベートコンテンツのHLS配信 with CloudFront
defunty
0
370
CSS Module・CSS in JS抗争の過去と現在
defunty
1
210
アクセシビリティ in 令和
defunty
0
40
Other Decks in Programming
See All in Programming
【やさしく解説 設計編・中級 #4】ルールの寿命と、システムの年輪
panda728
PRO
2
140
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
270
Apache Hive: そしてCloud Native Lakehouseへ
okumin
1
140
なぜ型を書くのか? TSKaigi2026で改めて考える #tskaigi_smarthr
kajitack
0
380
【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ
panda728
PRO
2
270
「正の参照」と 「負の導出」で組む ハーネスエンジニアリング
cottpan
1
140
【やさしく解説 設計編・中級 #1】一つの車に、運転手は一人 ~ある倉庫システムの事例から~
panda728
PRO
0
180
Laravelで学ぶ Webアプリケーションチューニング入門/web_application_tuning_101
hanhan1978
4
800
PHPだって関数型したい 〜できること、できないこと〜 / fp-in-php
jsoizo
0
210
才能?センス?知らん、 続けたもん勝ちだ。-- 結婚・出産・癌を越えてなお、私がプロダクトを創り続ける理由
16bitidol
2
860
AIキャラアプリkaiwaの低遅延音声通話基盤をどう作ったか - AWS Gravitonで支える低遅延・低コストAI Agent基盤
mogamit
0
170
Even G2とAWSで推しのエージェントを召喚しよう!
har1101
1
170
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
37
7.4k
Building Adaptive Systems
keathley
44
3.1k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
200
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
190
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.4k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
610
We Have a Design System, Now What?
morganepeng
55
8.2k
So, you think you're a good person
axbom
PRO
2
2.1k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
350
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.8k
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
410
Transcript
SPA での認証方法に関する マサカリぶん投げ会場はこちらです ->
SPA での認証はどうしてますか?
Session-Based authentication cookie にsessionID を保存する sessionID をキーにして、情報はサーバー側に保存 従来のモノリシックなアプリケーションで利用 Token-Based authentication
いわゆるJWT のようなtoken を使った方式 どこにセッション情報を持たせるかは自由(要件次第)
JWT (JSON Web Token) とは JOSE (Javascript Object Signing and
Encryption) の規格の一つ。 JOSE は安全にやり取りを行う必要がある情報をJSON で取り扱うため のフレームワークで、以前はこういった情報がASN.1 やXML として取 り扱われていた。 JWT は対象のデータについて、完全性の担保を行う場合はJWS (JSON Web Signature) に、暗号化を行う場合はJWE (JSON Web Encryption) に基づいている。 (必ずしも完全性の担保や暗号化が行われている訳ではない)
ここから仮想ディベート (実在する人物の見解とは異なります)
Session-Based 派 token をlocalStorage に保存するとXSS 脆弱性が存在する場合に盗ま れる token の有効期限が来るまで無効化できない 対策としてログアウトするときにtoken
を無効化(ブラックリス トに追加)させる処理が必要 パスワードを変えたときにtoken も再発行しなければならない セキュリティリスクを増やす上に手間もかかるので意味がない
Token-Based 派 API サーバをステートレスにできるのでスケールアウトが楽 毎回sessionID からDB 参照しなくて良いのでパフォーマンス高い そもそもXSS 脆弱性が存在することが問題では? XSS
脆弱性があるならそれはtoken 云々の話ではない XSS が怖いのならlocalStorage じゃなくてCookie のHttpOnly 属性で 制御すれば良い トークンの有効期間を短くすれば漏洩した場合のリスクを抑えられ る
Session-Based 派 スケールアウトのことを考えるなら、セッション情報をインメモリ ではなく独立したストレージで管理すればいい話 Third-party software を利用している限りXSS 脆弱性のリスクは存在 する そもそもHttpOnly
はJS で直接cookie を取得できないようにするだけ トークンの有効期限が切れるたびにログインしなければならない
Token-Based 派 だからサーバーでセッション管理したくないって言ってんだろ リスクを最小限に抑えた上でそれに見合う利便性が得られるという 話をしている リフレッシュトークンを使ってtoken の再発行ができる仕組み (Sliding Sessions) をつくれば良い
収拾がつきません
仮想ディベートはここまで 以下、個人の見解
session とtoken のどちらで認証すべきか? 要件次第。 センシティブな情報をクライアント側で管理すべきではないが、「セ ンシティブな情報」の定義と、その情報にリスクを課した場合に開 発・メンテナンスの労力がどれだけ下がるかによる。 完全にRestful なAPI サーバー(外部クライアントへの提供・micro
service など)であればセッション管理を行う必要がないため、token が適している。
token はlocalStorage に格納して良い? 知られて困る情報でなければどうでも良い。 XSS 脆弱性が存在する限り、localStorage でもcookie でもそんなにリス クは変わらない認識。 そもそもcookie
に保存するのであればSession-Based と比較して大し たメリットがないし、むしろサーバーサイドの実装コストが重そう。 auth0 を利用すれば、localStorage にもcookie にも保存しない方法でリ スクを最小限に抑える実装ができる。ただし、ユーザがThird-Party cookie をブロックした状態だと問題が出る。
token でセッション管理して良い? 見られて困る情報 ... 以下略 ただし、ほとんどの場合は何かしら重要な情報をサーバー側で持たせ る必要があると思うので、サーバー側に管理責任を負わせるのが筋な 気がする。 ついでにクライアント側で管理する場合は文字数制限に注意する必要 がある。
token の有効期限はどれくらいにすべき? 要件次第だが、基本的には短くする(1 分〜10 分とか)。 期限切れのたびにログインし直すのはユーザーに優しくないので、 OAuth で言うところの、有効期限を長く取ったリフレッシュトークン を併用する。 この場合、『token
』の役割はアクセストークンと呼ばれるものにな る。
アクセストークンの期間を短くしてもリフレッ シュトークンが漏れたら意味なくない? はい。 なので漏洩が判明した場合、該当のリフレッシュトークンをブラック リストに入れる必要がある。 Session-Based でやっているように、サーバーサイドのログアウト時 に
じゃあリフレッシュトークンを使わずにtoken の有効期限を長くするのと変わらないのでは? token をブラックリストに入れるシステムの場合、アクセスするたび にブラックリストDB を参照する必要があるため、リフレッシュトーク ンが存在することでサーバー負荷を減らすことができる。 サーバー負荷軽減の代わりにリスクを無視しているとも言えるが、や はり要件次第。 また、ユーザーを強制的にログアウトさせたい場合はアクセストーク
ンの有効期限を極端に短くすることで実現できる。
結論 「楽だからJWT 」はなし(そもそも楽ではない場合が多い) 認証を外部サービスに頼る理由でのToken-Based はあり ノウハウがなくても使えるライブラリやサービスを使う(それでも 適切な知識は必須) モバイルアプリのようなCookie の使えないプラットフォームや、マ イクロサービスのような完全ステートレスであればToken-Based
が 良さそう token としてsessionID を持ち、サーバーで管理することでJWT の機 能を使ったセッション管理というハイブリッド手法もある(あるの か?)
参考 JWT ハンドブック 情報セキュリティ技術動向調査(2011 年下期):IPA 独立行政法 人 情報処理推進機構 Javascript Object
Signing and Encryption (JOSE) — jose 0.1 documentation RFC 8725: JSON Web Token Best Current Practices Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
どうしてリスクアセスメントせずに JWT をセッションに使っちゃ うわけ? - co3k.org HTML5 のLocal Storage を使ってはいけない(翻訳)|TechRacho
(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS 株式 会社 JWT でセッション管理してはいけない - Qiita そもそもJWT に関する私の理解は完全に間違っていた! - ブログな んだよもん SPA+SSR+API で構成したWeb アプリケーションのセッション管理 - ペパボテックブログ
JWT 認証、便利やん? - ブログ JWT 形式を採用したChatWork のアクセストークンについて - Chatwork Creator's
Note JWT を使った今どきのSPA の認証について 認証用トークン保存先の第4 選択肢としての「Auth0 」 - ログミー Tech
Refresh Token Rotation Authentication - Password & user management -
Amplify Docs セキュリティ視点からの JWT 入門 - blog of morioka12 Cookie - JWT などのToken をlocalstrage(HTML5 の) に保管すること について|teratail クロスサイトスクリプティング(XSS) 対策としてCookie のHttpOnly 属性でどこまで安全になるのか - YouTube
徳丸 浩さんはTwitter を使っています 「そもそもJWT をセッション 管理に使うと、ログアウト時にセッション情報を破棄できず… 続き は質問箱へ #Peing #
質問箱 https://t.co/St1Cggr2j2 」 / Twitter Auth0 のSilent Authentication ( サイレント認証) とRefresh Token Rotation ( リフレッシュトークンローテーション) を完全に理解した ( い) - 一から勉強させてください Refresh Token : どのような場合に使用し、どのように JWT と相互 作用するか 2020 年版 チーム内勉強会資料その1 : JSON Web Token - r-weblife "JWT= ステートレス" から一歩踏み出すための考え方