「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
OAuth2/OIDCには結構詳しいつもりだケド、出所が長々と解らなかった話が
「PHP Conference Japan 2021」で議論されていたので、まとめてみた。
詳細 †
Session云々とかCookie云々とか
Session云々 †
- これは、Session情報をサーバに持たせるのではなく、
CookieにJWTとして持たせるとステートレスに出来るよね？
と言う主張が出所の話らしいが、どうも、認証機能も込で言及されているらしく、
ログアウトをどうやって実装するのか？みたいな問題提起がされていたりする。
- ...しかし、そんなことはしないのでパス。
（Webサービスだとスケーラビリティを求められるのでやりたくなるらしい）
- ステートフルで更新に強いものがステートレスで更新に弱くなる。
- iatなどを付与すれば、と言う話もあるが、スライディング有効期限に対応できない。
Cookie云々 †
Cookie †
- JWTに限らず、認証情報をCookieに保存してAPIアクセスする場合の話。
- XSSがアレば、Cookieは盗まれる可能性がある。
LocalStorage? †
- コチラは、「Authorization: Bearer JWT」の場合の話。
- 危ないと言われているが、Cookieよりは安全と言う説が有力。
- Originが異なれば、対象のLocalStorage?にアクセスできない。
対策 †
- セキュアと言われているモノには、SameSite?が前提であるモノも多いので、
CORSをする場合は、結局、アプリをセキュアにして行く必要がある。
- Defence in DepthしてもWeakest Linkになるので、
大差ない基盤の１層に注力しても全体としてセキュアにならない。
- SPAのXSSのパターンを理解しておく必要がある。
ステート †
ステートレス・ステートフル
ステートレス †
JWTは、そもそもステートレス。
ステートフル †
- トークン管理を実装するために、ステートフル化するケースがある。
- トークン無効化だけならステートレス（無効化するトークンのjtiダケを保持）に出来るが、
発行済トークン一覧などを実装する場合、ステートフル（発行先とjtiをサーバーに持たせるよう）にする必要がある。
参考 †
Qiita †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
