Carpe Diem

備忘録。https://github.com/jun06t

OpenIDやOAuthやらの比較

概要

色んな種類がありますが、各手法の流れ、メリット・デメリットを整理するためにまとめました。
今回比較するのは以下の4つです。

シーケンス図ではわかりやすさのため以下のようにしています。

名称 説明 今回の例
UserAgent ユーザ User
Relying Party サービス提供者 Server
Identity Provider SSO用APIの提供者 Google

またRelying Party

  • Confidential Client:サーバあり。
  • Public Client:スマホやJSアプリ。サーバなし。

がありますが、今回は前者を前提としています。

OpenID

最初に簡単な認証方法として出てきたのがOpenIDです。

シーケンス図

f:id:quoll00:20150124204751p:plain

メリット

署名の検証作業があるのでセキュリティ上問題無いですし、Googleにサービスの登録作業とかもないので簡単にSSOを導入できます。

デメリット

普及する前に上位互換?であるOAuthが普及してしまったので普及しませんでした。Googleさんも2015/04に廃止予定です。

OAuth2.0認証(Authorization Flow)

OpenIDのように認証だけでなく、各APIも柔軟に利用できるよう作られたのがOAuthです。
そのうちのユーザ情報を取得するAPIを利用して認証に使われるようになりました。
スマホサービスの台頭により一気に普及した感じがあります。

シーケンス図

f:id:quoll00:20150124204832p:plain

メリット

サーバ経由ならclientSecretが漏れないのでセキュリティ上問題ない認証を実装できます。
ポイントはcodeがそのServerのサービス用に発行されたものであるかどうか、clientIDclientSecretを使ってちゃんと検証している点です。
なのでcodeをすり替えられても検証時に怒られるので問題がありません。
ただしCSRF攻撃の可能性はあるのでstateの検証はした方がいいです。

デメリット

IdPに登録作業が必要な点くらいでしょうか。

HTTPSでもcodeが漏れるケースがあり、その場合はcode置換攻撃が可能になるようです

HTTPS でも Full URL が漏れる?OAuth の code も漏れるんじゃね?? - OAuth.jp

OAuth2.0認証(Implicit Flow)

元々クライアント(スマホ側)だけでサクッと認証ができたらということで使われるようになった手法です。
ただし当然ながら色々な処理を省いたためにセキュリティ上問題が多いです。
今回のようなサーバ経由のConfidential Clientでもこの認証だと抜け道があるので使用すべきでないです。

シーケンス図

f:id:quoll00:20150124204843p:plain

メリット

Authorization Flowより簡単に実装できそう(理解していないから)

デメリット

ユーザのところでAccessTokenを別ユーザ用にすり替えられるとそのユーザでログインできちゃいます。
このAccessTokenは別のサービスのものでもOKなんです。だってGoogle側は単にユーザ情報を取得するAPIを提供しているだけなので、そのAPIに「どこどこのサイトのAccessTokenかどうかチェックする」なんて機能はありません。 なので悪意ある人が悪意あるサービスBを提供していると、そのサービスBのAccessTokenを使ってサービスAでなりすましログインできます。

OpenIDConnect

元々OAuthにログイン認証機能なんてなくて、上記の2つはサービス提供側(Server)が外部APIGoogle)から受け取ったユーザ情報を元に勝手にログイン認証を実装してしまったのが問題でした。
なのでちゃんとOAuthで認証できるようにと作られたのがOpenIDConnectです。
認証用なので先程のImplicit Flowの流れでもセキュリティ上問題なく実装できます(ちゃんと実装すれば)。

シーケンス図

f:id:quoll00:20150126192107p:plain

メリット

署名の検証をするので入れ替え攻撃にも対応できセキュリティ上問題無いです。
ユーザの特定にはAccessTokenは用いず、ID Tokenの中のユニークIDを使用します。

デメリット

IdPによっては署名の検証機能を提供してないので自前で検証することになります。

ソース