こんなエントリを見つけました。
http://www.enrise.com/2011/03/sso-oauth-openid-omg/
内容はこのような感じです。
- AuthNとAuthZの違い
- AuthZのフローがAuthNを包含しているために"SSOのためのOAuth"が広く使われている現状
- 結論 : "SSOにOAuthやその他AuthZのしくみを使うことは正しい方法ではない"
OpenID/OAuthに関わった人間であれば一度は考えたことがある話ですね。
現在、OAuth 2.0の策定が進められており、既に"その一部"は実装され始めています。
OAuth 2.0は、あくまでAuthZ Protocolとして考えられているものであり、上記エントリで提起されている"potential problems"は解消されるわけではありません。
そこで、今回はSSOのためにOAuthとOpenIDの機能を振り返り、それを踏まえて策定が進んでいるOpenID ABC(OpenIDの次の仕様、ABC=Artifact Binding and Connect)が目指している機能を紹介します。
最初に、SSOのためのOAuth(以下、OAuth for SSO)について少し振り返ります。
※ SSOっていう言葉は人によって定義があいまいですね。ここではおおざっぱなアカウント連携という意味合いですので細かいことは気になさらず。。。
OAuth for SSOの特徴
上記エントリにもあるとおり、現状でSSOっぽい使われ方がされているOAuthは以下の機能を持っています。
- AuthZ Flow + Profile APIなどによるユーザー情報の取得 ≒ AuthN結果の取得
Twitterアカウントでログインさせるサービスを作ろうと思ったらOAuthだけで十分ですよね。
SSO機能を提供するためだけにOpenIDを実装しなくても、OAuthを実装して自分たちが持っているデータ、サービスを外部アプリケーションに提供しつつSSO機能としても使ってもらえそうです。
OAuth 2.0になると実装もより簡略化される部分もあり、ますますOAuthの実装が広まりそうです。
ここで、OpenIDがUser-Centric Identityを目指していることに対し、"Vendor-Centricである"ことに触れておきましょう。TwitterのOAuthを利用する場合には、"TwitterのOAuth機能"を利用しなければなりません。Facebookもしかりですね。Jan Rain Engage(RPX)をご存知でしょうか？OAuthを実装している大規模なユーザーを幅広く取り入れようと思うと、たくさんのOAuth SPのロゴが並ぶでしょう。これでは、OpenIDのような"Nascar Problem"ですね。
OAuthのScopeが引き起こす混乱についても触れておきましょう。
SSOのためだけにOAuthを利用したい場合でも、そのようなScopeがついていないSPがあります。
まぁ、そういうとこはSSOさせるつもりでOAuth実装したわけじゃないのでしょうけど。。。不適切なScopeによるAuthZの要求は、ユーザーの不信感を呼ぶ可能性があります。TwitterはRead権限でもDMを見れます。「ちょっと相談があります。詳細はDMで送ります」なんていうTweetを見かけますが、そのDMの内容、外部のClientから見られているのではないですか？
次に、今のOpenIDとOAuthの両方に足りない機能について書きたいと思います。
OpenID/OAuthでも足りない機能
私が考える足りない機能は、以下の2点です。
- セッション管理
- 分散した属性情報へのアクセス
OpenIDでもOAuthでも、大規模なシステム同士をつなぐ場合、ユーザーから見て同一のシステムに見える場合などはセッションの不整合が課題になります。
以前のエントリでY!モバゲーのログアウトについて触れたことがありましたが、基本的にIdPとRPのセッションは非同期なので無理やり同期させる処理を実装する必要があります。
OpenIDのImmediateモードを利用することでオートログインに近い実装は可能ですが、ベストプラクティスと呼べるような使い方はあるのでしょうか？それに対し、同時に全てのRPからログアウトするシングルサインアウト/シングルログアウト機能については定義されていません。このようなセッション管理をシンプルに実装できるように定義することができれば、今よりもOpenIDがSSOの手段として利用しやすくなるのではないでしょうか。
分散した属性情報という点についてですが、現在のOpenIDのAXによる属性交換ではIdPのみが属性情報を管理しています。OAuthのリソースアクセスではSP≠Resource Serverという関係でありながらも、複数のSPから発行されたTokenを用いてリソースアクセスさせるようなユースケースはまだ見られません。OAuth 2.0ではSAMLとの連携なども考慮されていますが、OpenIDでも"分散されているユーザーデータ"に安全にアクセスできるしくみが必要です。
OpenID ABCが目指す機能
ここまでの内容と、OpenID自体の改善すべき機能を踏まえ、OpenID ABCでは次のような機能の定義が進められています。
- Discovery and metadata : Webfingerなどの使いやすい仕組み、XRDなどを用いたmetadataの管理と提供
- Hybrid with AuthZ : AuthZが必要な時はベースとなるOAuth 2.0のしくみを利用
- Session Management : オートログイン/シングルログアウト
- Distributed Attribute Providers : 分散された属性情報へのアクセス機能を提供
これで、もうOAuth for SSOでいいじゃんとは言わせない！って、ABCの中の人たちは思っているはずです。期待しましょう。
そういえば、あの有名なIdentityWomanがこう言っていました。"User-Centric Identityは死んでいません。"
Identity Woman - Indpendent Advocate for the Rights and Dignity of our Digital Selves
