Share
Embed
Transcript
23 slides
-
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 を取得できないようにするだけ トークンの有効期限が切れるたびにログインしなければならない -
session とtoken のどちらで認証すべきか? 要件次第。 センシティブな情報をクライアント側で管理すべきではないが、「セ ンシティブな情報」の定義と、その情報にリスクを課した場合に開 発・メンテナンスの労力がどれだけ下がるかによる。 完全にRestful なAPI サーバー(外部クライアントへの提供・micro
service など)であればセッション管理を行う必要がないため、token が適している。 -
token はlocalStorage に格納して良い? 知られて困る情報でなければどうでも良い。 XSS 脆弱性が存在する限り、localStorage でもcookie でもそんなにリス クは変わらない認識。 そもそもcookie
に保存するのであればSession-Based と比較して大し たメリットがないし、むしろサーバーサイドの実装コストが重そう。 auth0 を利用すれば、localStorage にもcookie にも保存しない方法でリ スクを最小限に抑える実装ができる。ただし、ユーザがThird-Party cookie をブロックした状態だと問題が出る。 -
結論 「楽だから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= ステートレス" から一歩踏み出すための考え方