OpenIDConnectとOAuth2.0について調べてみた。
端的にまとめると、
- 「OpenIDは紹介状で、OAuthは合鍵」
- OAuth2.0のImplicit Flowはトークン置き換え攻撃のリスクがあるのでそんな時はOpenIDConnctを使いましょう
OpneIDによる認証
公証人（Identity Provider。Google等）に紹介状を書いてもらい
自分が自分である事を証明する。
氏名とメールアドレスに署名を打つイメージ
OAuthによる身分確認もどき
Oauthサーバ（Twitter等）は認証情報ではなく、合鍵を渡す。
合鍵で入れるから相手が本人だと理解する。
⇒合鍵を渡していることになり非常に危険
OpneIDConnectによる認証
家の合鍵ではなく紹介状のコピーの入っているロッカーの鍵を渡す。
受け取る側のフローはOAuthと同じ。しかし家には入れない。
またそのロッカーをUserInfo Endpointと呼ぶ。
「どういう認証（身元確認）をしたのか」などの本人の身元確認についての情報（メタデータ）をUserInfoロッカーの鍵と一緒に、紹介状にして送ります。
ここで送られてくる紹介状のことを、OpenIDトークンといいます。
OAuth2.0の問題点
クライアントシークレットを安全に保存できないImplicit Flowにおいて「トークン置き換え攻撃」が成立してしまいます。
アクセストークンだけでユーザ認証を行おうとしていることがだめなのですが、これはOAuth自体の問題ではありません。
認可のプロトコルであるOAuthをつかって認証もどきをおこなっているところが諸悪の根源です。
詳しくは以下ページにまとまっています。
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone
なお、理解するに当たって「OpenIDは紹介状で、OAuthは合鍵」であるという概念を理解しておくと非常に頭に入りやすい。
紹介状ではないので、別の合鍵を渡してしまえば検証できないということです。
非技術者のためのOAuth認証(?)とOpenIDの違い入門 | @_Nat Zone
ちなみに↑の崎村さんはOpenIDFoundationの理事長。どうりで分かりやすい。
問題の悪さ部分については以下のスライドも分かりやすい
Idcon11 implicit demo
対策
まあすでに上記のページで色々解説がされておりますが、OpenIDConnectを使うといい。
なぜかというとアクセストークンが置き換えられたとしてもIDトークンと合致しないので不正を検出できます。
まあつまり、認証は認証で認可は認可でちゃんとやりましょう。
その他
OepnIDConnectがどうして今の形式になったのかというのが以下にまとまっていた。
既存のユーザたちが出来るだけ影響少なく考えた結果こうなったのですね。
OpenIDファウンデーション・ジャパン — OpenID Connect, ふたつのトークンの物語
