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
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
360
CSS Module・CSS in JS抗争の過去と現在
defunty
1
200
アクセシビリティ in 令和
defunty
0
39
Other Decks in Programming
See All in Programming
なぜ型を書くのか? TSKaigi2026で改めて考える #tskaigi_smarthr
kajitack
0
140
Vue × Nuxt × Oxc どこまで使える?実運用の現在地
andpad
0
300
セキュリティの専門家じゃなくてもできる。「セキュリティ意識」をアップデートして サプライチェーン攻撃への耐性を高めよう。
tk3fftk
5
920
正しくソフトウェアを作る、前提を疑うための認知の視点 / doubt-premise
minodriven
21
7k
過去最大のMCPアップデート! 2026-07-28 RC版の謎に迫る
licux
6
390
PHPで使える日時の表現と、その知り方 #frontend_phpcon_do
o0h
PRO
0
260
鹿野さんに聞く!『TypeScriptコードレシピ集』で磨く実践力
tonkotsuboy_com
2
750
「AIで開発し、AIを届ける」をEvalでつなぐ 〜AIネイティブに始めるプロダクト開発の実践〜 / Connecting "Develop with AI, deliver AI" with Eval
rkaga
4
5.4k
そのテスト、説明できますか?~LWテスト戦略FW~のご紹介
nakahara
0
160
コンテキストの使い捨てをやめる — ビジネスルール駆動開発と miko —
ioki
0
230
ふつうのFeature Flag実践入門
irof
8
4.2k
OSもどきOS
arkw
0
590
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
225
10k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
A Tale of Four Properties
chriscoyier
163
24k
Bash Introduction
62gerente
615
220k
Navigating Weather and Climate Data
rabernat
0
230
GitHub's CSS Performance
jonrohan
1033
470k
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.3k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
610
Build your cross-platform service in a week with App Engine
jlugia
234
18k
[SF Ruby Conf 2025] Rails X
palkan
2
1.1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3.4k
We Have a Design System, Now What?
morganepeng
55
8.2k
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= ステートレス" から一歩踏み出すための考え方