![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>OAuth 2.0 セキュリティ関連トピック]] * 目次 [#a778907b] #contents *概要 [#hcb60b47] [[OAuth2/OIDC>OpenID / OAuth / OpenID Connect]]には結構詳しいつもりだケド、出所が長々と解らなかった話が~ 「PHP Conference Japan 2021」で議論されていたので、まとめてみた。 *詳細 [#p5b88ca8] [[Session云々>#iac9439e]]とか[[Cookie云々>#uab049ab]]とか **Session云々 [#uab049ab] -これは、Session情報をサーバに持たせるのではなく、~ Cookieに[[JWT]]として持たせるとステートレスに出来るよね？~ と言う主張が出所の話らしいが、どうも、認証機能も込で言及されているらしく、~ ログアウトをどうやって実装するのか？みたいな問題提起がされていたりする。 -...しかし、そんなことはしないのでパス。~ （Webサービスだとスケーラビリティを求められるのでやりたくなるらしい） --ステートフルで更新に強いものがステートレスで更新に弱くなる。 --iatなどを付与すれば、と言う話もあるが、スライディング有効期限に対応できない。 **Cookie云々 [#iac9439e] -安全にTokenを取得しても、保存先の問題がある。 -話を聞いていると、どうも、[[Cookie>#t8e2c5fe]] vs [[LocalStorage>#la4c6878]] と言う構図らしい。 ***Cookie [#t8e2c5fe] -[[LocalStorage>#la4c6878]] より安全という主張もあるがそんな事も無い感じ。 -[[JWT]]に限らず、認証情報をCookieに保存してAPIアクセスする場合の話。 -[[XSS>XSS対策の実装方針]]がアレば、Cookieは盗まれる可能性がある。 -[[CORSのAccess-Control-Allow-Credentialsの設定>CORS (Cross-Origin Resource Sharing)#j8e6762e]]に問題があると、~ [[CSRF(XSRF)>CSRF(XSRF)対策の実装方針]]的な攻撃が成立し易くなる（ただし、以下のハードルもある）。 --POSTでSameSite=Noneであること。 --[[CSRF(XSRF)>CSRF(XSRF)対策の実装方針]]のチェックが実装されていないこと。 ***LocalStorage [#la4c6878] -LocalStorageとは[[Web StorageのLocalStorage>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?HTML5%20JavaScript%20API#wb728540]]を指す。 -コチラは、「Authorization: Bearer JWT」の場合の話。 -コチラは、「Authorization: Bearer JWT」に限定された場合の話。 -危ないと言われているが、[[Cookie>#t8e2c5fe]]よりは安全と言う説が有力。 --[[OAuth2/OIDC>OpenID / OAuth / OpenID Connect]]は、そもそも、CORS用に考えられた仕組みで、 --Originが異なれば、対象のLocalStorageにアクセスできない。 --SPAの[[XSS>XSS対策の実装方針]]対策は必要になる。 ***対策 [#f81b8169] -セキュアと言われているモノには、SameSiteが前提であるモノも多いので、~ CORSをする場合は、結局、アプリをセキュアにして行く必要がある。 --[[XSS対策>XSS対策の実装方針]] --[[CSRF(XSRF)対策>CSRF(XSRF)対策の実装方針]] -Defence in DepthしてもWeakest Linkになるので、~ 大差ない基盤の１層に注力しても全体としてセキュアにならない。 -SPAの[[XSS>XSS対策の実装方針]]のパターンを理解しておく必要がある。 **ステート [#h7489c17] [[ステートレス>#q9066eea]]・[[ステートフル>#r53594ce]] ***ステートレス [#q9066eea] [[JWT]]は、そもそもステートレス。 ***ステートフル [#r53594ce] -トークン管理を実装するために、ステートフル化するケースがある。 -トークン無効化だけならステートレス（無効化するトークンのjtiダケを保持）に出来るが、~ 発行済トークン一覧などを実装する場合、ステートフル（発行先とjtiをサーバーに持たせるよう）にする必要がある。 *参考 [#x320e1e5] -認証用トークン保存先の第4選択肢としての「Auth0」 - ログミーTech~ https://logmi.jp/tech/articles/324349 -Web Storage: セッショントークンのマシな手段~ cookieとセキュリティ面を比較してみる | POSTD~ https://postd.cc/web-storage-the-lesser-evil-for-session-tokens/ -SPAセキュリティ入門～PHP Conference Japan 2021~ https://www.slideshare.net/ockeghem/phpconf2021spasecurity **Qiita [#qb9dd735] -JWTでセッション管理してはいけない - Qiita~ https://qiita.com/hakaicode/items/1d504a728156cf54b3f8 -SPAのログイン認証のベストプラクティスがわからなかったので~ わりと網羅的に研究してみた〜JWT or Session どっち？〜~ https://qiita.com/Hiro-mi/items/18e00060a0f8654f49d6 -SPA認証トークン、Cookieに保存するか？LocalStorageに保存するか?~ https://qiita.com/T-Tokumori/items/b531d2c8612747dabe1e -認証トークンをWeb Storageに保存して良いか？~ https://qiita.com/some-nyan/items/d51c50de5f0663cf3bea ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
