OpenID や OAuth の役割と、既存のシングル・サインオンとの違い

OpenIDやOAuthと、LDAPやSAMLなどのシングル・サインオン(Single Sign On)は似ているようで違う。その違いをちゃんと理解できていないので、勉強モードで調べた情報をまとめてみた。かなり長くなってしまったので、まずはまとめから。

既存のシングル・サインオンは、本人性とシステム間の相互信頼がベース

そもそものニーズと、歴史的経緯から以下のような方面に強い。

  • イントラネットの個人電話帳から、ディレクトリーサービスに進化した
  • ディレクトリーサービスの個人の役割に応じて、アクセス権限が与えられた
  • 社内のディレクトリ、サービス間で認証モジュールを共有することで、シングル・サインオンを実現
  • イントラネットからインターネットに利用範囲を拡大

OpenIDやOAuthは、ウェブによるウェブのための仕組み

既存の認証システムやシングル・サインオンの延長ではなく、ウェブサイトに特化した新しい仕組み。

  • ウェブサイト(URL)の、ウェブサイト(OpenID Identity Provider)による、ウェブサイト(OpenID Consumer)のための認証プロトコル
  • ユーザの本人性の認証や、システム間の相互信頼は必須ではない。
  • 用途を絞り込むことで、既存のシングル・サインオンなどとも併用可能
  • 通常のウェブサイトと同じように、あらゆるサービスからアクセスされることが前提
  • どのウェブサイトを信用し、どのデータの利用を認可するかはユーザー次第だが、フィッシング対策など、これまでのウェブサイト向けのセキュリティー対策のアイデアが活用できる
  • 技術のスコープが絞られていることで、インターネットという自立分散的な環境に、柔軟に組み込むことができる

以下、既存のシングルサインオンの歴史的な経緯と比較しながら、OpenID, OAuthの位置づけを考えてみます。ただ、何ぶん認証系の技術知識が未熟なので、間違い等がありましたら、ぜひご指摘いただければと思います。

シングル・サインオンが生まれた歴史的な経緯

まずOpenIDなどのネット発祥の技術と、エンタープライズ系のシングルサインオンの違いについて。色々と検索していると、SunのPat Pattersonさんの講演資料を発見。ポッドキャストで実際の講演を聞くこともできます(英語)。

Pat Patterson : Superpatterns: Slides from Liberty Tokyo and TriLUG

LDAPやWeb Access Management、Single Sign-on、SAMLなどの技術が生まれた歴史的な経緯が、分かりやすく理解できました。プレゼン資料からポイントを抜き出させていただくと、

  • 10年前のLDAPは、簡単なディレクトリー・アクセスのプロトコルとしてスタート
    • eメールのアドレス帳、個人電話帳的な役割
    • 10万ユーザー・エントリーはかなり大規模な方
  • 現在のLDAPは、認証処理を中心にしたよりRDBMSなアクセスがメインに
    • ID / パスワードによるログイン
    • ロール(役割)に基づくアクセス管理
    • 1000万エントリーはざらにある

LDAPは標準化されたプロトコルでパフォーマンスもよかったので普及したが、以下のような問題があった。

  • 信用処理は集約化されたが、ユーザーはそれでも都度、何らかの認証手続きをする必要があった
  • 企業内の複数のアプリケーションが、それぞれ個別のディレクトリを持ってしまうケースが多かった

IDやパスワードを複数使い分けたり、異なるアプリケーションを利用する度にログインが求められる状況を改善するために導入されたのがWeb Access Management。認証、権限管理の機能を、個別のアプリケーションから、共通のWeb Access Management(WAM)ソリューションに集約。ブラウザcookieの利用、ProxyあるいはAgentベースのアクセスコントロールと組み合わせることで、シングルサインオンを実現した。これによって、上記の課題を解消。

ただし、単一のエンタープライズ・システムをこえた、エンタープライズ・システム間でのシングルサインオンには以下のような問題が残っていた。

  • ドメインが異なるとCookieは利用不可
  • システム毎に採用しているWAMソリューションのメーカーや製品が違うことがある

このような問題を解決するために、Single Sign On の標準化が必要とされ、そこで生まれたのがSAMLやLiberty Federation。これは、Microsoft の .Net passport などの中央集権的な認証システムに対する、カウンターアクションでもあった。SAMLにより、ひとつのIdentity Provider で、複数のサービスプロバイダーを利用できるようになり、エンタープライズ内の統一されたSingle Sign On が実現した。

Service Provider は、Identity Provider にSAML Authentication Request を送信して、そのSAML Response の内容から、ユーザーにコンテンツへのアクセスを許可するかどうかの判断をコントロールする。(SAMLの技術的な概要は、講演資料とポッドキャストで知ることができます。)

この段階になると、エンタープライズ・システムという領域を出て、インターネット上でのサービス連携にも使われるようになる。そして、OpenIDやOAuthなどの、WEBサービスから生まれた仕様とオーバーラップして見えるようになった。

エンタープライズでは、信頼性の担保されたシステム、ユーザーが前提

これからは、個人的な理解の整理です。シングルサインオンは、このような歴史的経緯で発展してきた。そのため、以下のような条件で利用されることが多い。

  • 当初の目的は、エンタープライズ・システム内で乱立する、多数のIdentity Providerを集約すること。
  • そのため、単一あるいは少数のIdentity Providerの認証によって、複数のサービスを利用するケースが多い
  • Identitiy Provider は、ユーザーという実在する人間のアイデンティティを認証(Authentication)する
  • 本人性を認証するため、サービス同士の相互信頼や、セキュアな転送経路が必要
  • 本人性を認証するため、Identityをもとにアクセス制御などの認可(Authorization)を、サービス側で設定する

つまり、シングルサインオンは、システム同士がお互いに信頼関係を構築することで、ログインという処理を共有し、システム全体としての無駄を省くことから始まった。その結果として、ユーザーは、IDとパスワードを複数入力しなくてもよい、というメリットが得られる。さらに、システムの信頼関係の構築を、単一のエンタープライズ・システム内から、システム横断、そしてインターネットに広げつつある。『ある特定の場所(Identity Provider)で認証(Authenticate)された、ユーザーの本人性』を信用することで、様々なサービス・アプリケーションが、コンテンツへのアクセスの認可(Authorize)をおこなえる仕組みとなった。

OpenIDと、OAuthは『何をしないのか?』

一方で OpenID と OAuth は、対象とする領域が、かなり意図的に絞り込まれた形でスタートしています。OpenID は、繰り返し、こう説明されています。

『Identity authentication not authorization』

URLというアイデンティティを認証する仕組みだけれど、オーソライズ(認可)ではない。ユーザーの本人性の認証と、それに基づいたAuthorization(認可)は、意図的にスコープから外されている。これは『できない』のではなく、『あえてやらない』という点が重要。

OpenIDは、URLという特定のアイデンティティの認証を、ウェブに親和性の高い方法でライトに実現する、新しい独立したイノベーションとして利用した方がよい。おおげさに言ってしまうと、『ウェブサイト(URL)の、ウェブサイト(OpenID Identity Provider)による、ウェブサイト(OpenID Consumer / Relying Party)のための認証プロトコル』

もし仮に、本人確認をしているウェブサービスがOpenID対応をして、そのOpenID Identity Provider で、本人性が確認された認証を提供しているように見えたとしても、それはたまたま、そのサービスがそのような条件を持っているにすぎない。したがってOpen ID Consumer(Relying Party) は、少なくともOpenIDの実装範囲内では、そのような本人性の認証を期待するべきではない。逆にいうと、本人性の認証を完全にスコーブ外とすることで、既存のシングルサインオンなどの仕組みと共存することができる。

あと、よくある質問として「自社の認証システムをOpenID対応したいけど、特定のOpenID consumer(自社のサービスなど)からのみ、利用可能にしたい」というケース。これに対する答えとしては、「OpenID Identity Providerは、原則としてすべてのConsumer(Relying Party)からの認証リクエストに応えるべき」という考えでよいのだろうか? そのような限定したサービス間のみの利用は、SAMLなどの既存のシングルサインオンの領域として、OpenID Identity provider はあくまでもオープンな認証サービスとして運用したほうが、趣旨にそうような気がする。通常のウェブサイトの閲覧のように、原則として誰に対してもオープンなアクセスを前提にして、アクセス制限はOpenIDより上のレイヤー、個別のウェブアプリケーションで行う方がすっきりする。

似たようなWEB系の認証システムである Googleの Auth for web apps では、OpenIDとはことなり、サービス事前登録制になっている。この場合、Consumerは、事前登録というGoogle Auth 個別の手順を踏む必要がでてきてしまう。

Google Auth For Web Apps

また、URLの認証にスコープを絞り込むことによって、既存のウェブサイトのセキュリティー対策のアイデアをOpen IDにも流用できる。例えば、悪意のあるフィッシング目的のOpenID consumer が、特定のOpenID Identity provider にリダイレクトするフリをして、IDとパスワードを盗もうとするケース。この場合は、OpenIDでログインする画面が、フィッシング・サイトでないということをユーザーが確認する必要がある。あるURLが、本当にそのサイトであるかを確認するためには、ウェブブラウザに警告を表示するなど、通常のフィッシング対策が有効だろう。OpenIDが直面すセキュリティー問題への対策は、こちらの記事に詳しい。

OpenIDをとりまくセキュリティ上の脅威とその対策 − @IT

また、Consumer側のセキュリティー対策として、信頼できるOpenID Provider のみへの認証を許すというホワイトリスト的な考え方は、「自分のサイトから、怪しげなウェブサイトにはリンクしない」という、わりとオーソドックスなウェブサイト運営のポリシーと似ている気もしました。

このようにOpenIDは、URLをベースにした認証という限定したスコープを持つことで、既存のウェブサイトの仕組みやセキュリティー対策、あるいは他の認証システムとの親和性を高めているのではないでしょうか。

OAuthは、ユーザーの役割認証ではなく、ユーザー自身がデータ共有を認可する

既存のウェブアクセス・マネージャーは、ディレクトリー・サービス内でのユーザーの役割権限に応じて、アクセスできるウェブページ(サービス)を制限します。例えば、「部署Aに所属する山田さんは、社内wikiとブログの、部署Aのページにのみアクセスできる」というような感じ。ここでは、本人性の認証と、サービス同士の相互信用が前提となっている。「山田さんであることが確認できて、異なるサービス同士が互いに信用を確立していれば、山田さんの作成したデータを共有してもよい」というポリシーが設定可能。

一方の、OAuthについては、Pat Pattersonさんが上記のプレゼン中で、このように表現しています。

『Authorization rather than Authentication』

『認証というよりは、認可』。OAuthでは、本人性の認証と、サービス同士の相互信頼の確立は、必須条件ではない。OAuthはその代わりに、サービス同士でデータ共有が必要になったら、その都度、ユーザー自身が可否を認可する。この方法だと、共有したいデータのあるウェブサイト(URL)のIdentityを認証すればよいので、本人性の認証は必要ない。また、データ共有のポリシーも、ユーザーが『どのデータを、どの範囲まで共有してよいか』、都度認可するので、事前にサービス同士で相互信頼ポリシーを確立しておく必要がない。

まとめ:

やたらと長い記事になってしまいましたが、以上の経緯をざっくりまとめてみると、こんな感じでしょうか。

既存のシングル・サインオンは、本人性とシステム間の相互信頼がベース

そもそものニーズと、歴史的経緯から以下のような方面に強い。

  • イントラネットの個人電話帳から、ディレクトリーサービスに進化した
  • ディレクトリーサービスの個人の役割に応じて、アクセス権限が与えられた
  • 社内のディレクトリ、サービス間で認証モジュールを共有することで、シングル・サインオンを実現
  • イントラネットからインターネットに利用範囲を拡大

OpenIDやOAuthは、ウェブによるウェブのための仕組み

既存の認証システムやシングル・サインオンの延長ではなく、ウェブサイトに特化した新しい仕組み。

  • ウェブサイト(URL)の、ウェブサイト(OpenID Identity Provider)による、ウェブサイト(OpenID Consumer)のための認証プロトコル
  • ユーザの本人性の認証や、システム間の相互信頼は必須ではない。
  • 用途を絞り込むことで、既存のシングル・サインオンなどとも併用可能
  • 通常のウェブサイトと同じように、あらゆるサービスからアクセスされることが前提
  • どのウェブサイトを信用し、どのデータの利用を認可するかはユーザー次第だが、フィッシング対策など、これまでのウェブサイト向けのセキュリティー対策のアイデアが活用できる
  • 技術のスコープが絞られていることで、インターネットという自立分散的な環境に、柔軟に組み込むことができる

このように異なった歴史的背景、ニーズから発展してきた二つの技術が、インターネットという同じ領域で出会い、機能的にオーバーラップしてきたのでしょうか。と、ここまで整理して、shinichitomitaさんの記事に、なるほどと膝をうちました。

SAML, OpenID, 双方向信頼関係』 より

でも、そもそもIdPが抱えているところのアイデンティティ情報っていうのは、もともとユーザの持ち物であって、IdPは預かってくれているだけなのではないのか?それならば、アイデンティティを他のサービスに持ち運ぶか持ち運ばないかってのは、実際の所有者であるユーザによって決定されるべきではないのか?

たぶんこれがUser-Centiric Identityという思想(?)で、アイデンティティをIdPが保有する資産の一部であると考える Domain-Centricなモデルと立場的に決定的な違いがある。User-Centric Identityでは、どのアイデンティティを利用するのか、あるいは利用しないのかの決定は、IdPでもRPでもなく、ユーザ自身にある。アイデンティティ情報の利用先をIdPが制限している状態というのは、決してUser-Centricとは言い難い。

認証、シングル・サインオンという技術は、エンタープライズという、どちらかというと中央集権的な領域で発達してきたけれど、インターネットという徹底した自立・分散環境では、改めて再発明される必要があったのかも。インターネットでは、様々なシステムやブラウザが、ウェブ標準というプロトコルに沿って、ゆるやかに連携しています。そのような環境では、厳密な本人性の認証や、システム間の相互信頼を前提とすることが難しい。逆に、スコープの対象を絞り込む『あえて、やらない』ことによって、様々な周辺システムと連携がしやすくなる。

ここでのシステム連携には、『ユーザー自身による判断』も含まれている。「どのウェブサイトを信用するか」「どのデータの共有を認可するか」という判断を、中央のシステムに依存するのではなく、ユーザー自身に移譲してしまう。いわば人間(ユーザー)を、最も高度な判断が可能なシステムとして、自立・分散処理のなかに組み込んでしまう。シンプルがゆえに、かなりラディカルな思想を持っているのかもしれません。

と、ここまで長々と書いてきたら、まさに知りたかった議論が盛り上がっている! これから、さらに勉強させていただきます。