マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

OAuth2/OIDCには結構詳しいつもりだケド、出所が長々と解らなかった話が
「PHP Conference Japan 2021」で議論されていたので、まとめてみた。

詳細

Session云々とかCookie云々とか

Session云々

これは、Session情報をサーバに持たせるのではなく、
CookieにJWTとして持たせるとステートレスに出来るよね?
と言う主張が出所の話らしいが、どうも、認証機能も込で言及されているらしく、
ログアウトをどうやって実装するのか?みたいな問題提起がされていたりする。

...しかし、そんなことはしないのでパス。

(Webサービスだとスケーラビリティを求められるのでやりたくなるらしい)

Cookie云々

  • 安全にTokenを取得しても、保存先の問題がある。
  • 話を聞いていると、どうも、Cookie vs LocalStorage と言う構図らしい。

Cookie

  • LocalStorage より安全という主張もあるがそんな事も無い感じ。
  • JWTに限らず、認証情報をCookieに保存してAPIアクセスする場合の話。
  • XSSがアレば、Cookieは盗まれる可能性がある。

LocalStorage?

  • コチラは、「Authorization: Bearer JWT」の場合の話。
  • 危ないと言われているが、Cookieよりは安全と言う説が有力。
  • OAuth2/OIDCは、そもそも、CORS用に考えられた仕組みで、
  • Originが異なれば、対象のLocalStorage?にアクセスできない。

対策

  • セキュアと言われているモノには、SameSite?が前提であるモノも多いので、
    CORSをする場合は、結局、アプリをセキュアにして行く必要がある。
  • Defence in DepthしてもWeakest Linkになるので、
    大差ない基盤の1層に注力しても全体としてセキュアにならない。
  • SPAのXSSのパターンを理解しておく必要がある。

ステート

ステートレスステートフル

ステートレス

JWTは、そもそもステートレス。

ステートフル

  • トークン管理を実装するために、ステートフル化するケースがある。
  • トークン無効化だけならステートレス(無効化するトークンのjtiダケを保持)に出来るが、
    発行済トークン一覧などを実装する場合、ステートフル(発行先とjtiをサーバーに持たせるよう)にする必要がある。

参考

Qiita


Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-10-04 (月) 14:46:33 (17d)