「[[マイクロソフト系技術情報 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になるので、~
大差ない基盤の1層に注力しても全体としてセキュアにならない。

-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]]

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS