docomoのOpenIDの実装周りについて
23:47 |
技術的なツッコミをしてる人があんまり居ない気がする。OpenIDに対応してるのにOpenID入力欄にi.mydocomo.com入れてもログイン出来ないみたいな人が何人かいるだろうから、後学のためにメモしておく。日本のインターネットがどうあるべきかについてはここでは述べない。
用語の定義と参考文献
- OP(OpenIDを提供する側)
- RP(OpenIDを利用する側)
- docomo IDの仕様書 https://i.mydocomo.com/docomoid/utility/o-3.html
- OpenID2.0仕様書日本語訳 http://openid-foundation-japan.github.com/openid-authentication.html
現状
- docomoのOpenIDは現状多くのサイトで使えない。
- 単純に言うと、RP側の実装に対する要求が厳しい。
- 具体的にはImmediateモードの「禁止」とRP Discoveryが必須であるため。
- 要求が厳しいのはセキュリティ上の理由で、docomoの人がそれなりに色々考えて実装したのが伺える。
Immediateモード非対応
openid.modeにcheckid_immediateを指定された場合、ユーザーが既に「このサイトは信用するよ」と許可を与えている場合は、確認画面を出さないで即座にログインが完了する。checkid_immediateには対応しなくても良いのだが、その場合は「setup_needed」というレスポンスを返すことになっている。docomoの場合これが返ってこない。これはOpenIDの仕様に反している動作になる。
- で、setup_neededすら返さないで即座にエラー返して終了ってのに関しては理由が良く分からない。
- セキュリティ上の理由なら具体的にどういう攻撃が考えられるのかを知りたい。
- RP側に制御が戻らないので、docomoを特別扱いしないといけない。もしくはcheckid_setupをデフォルトにする必要がある。
RP Discovery必須
OpenID 2.0の場合、OpenIDログインするときに自分のidを入れなくてもOpenID提供者のドメイン名を入れるだけでログインできる。例えばyahoo.co.jpとかmixi.jpとかlivedoor.comとかで良い。これを実現するために、YadisってプロトコルでXRDSっていうXML文書を返す仕組みがある。
RP側もYadisプロトコルでXRDSファイルを見つけられる状態にしておくことで「OpenIDでのログインに対応している」ことをdiscovery出来るようになる。そしてこれが必須になっているのは、return_toのURLをOP側で検証することが目的だろう。
例えばdocomoでログインボタンをつけてるdocorekiというサイトではこんなXRDFファイルを返している。
<?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/return_to</Type> <URI>https://docoreki.jp/users/login</URI> </Service> </XRD> </xrds:XRDS>return_toを改竄したリクエスト
return_toに指定されたURLを書き換えることで、RP側が「本来想定しているlogin先のURL」ではないURLに対してOpenIDのレスポンスを送ってしまうことになる。OP側がcheckid_immediateを許可、かつ、ユーザーがRPを信頼済み、かつ、RP側にオープンリダイレクタが存在している場合には問題が大きくなり、ユーザーは意図せずに認証情報を他のサイトに送ってしまうことになる。ここら辺の話はOpenID+セキュリティでググれば出てくる。
RP側がRP Discoveryに対応している場合、OPはXRDSに記述されているURIをチェックすることでopenid.return_toがRPが意図した値と相違ないかどうかをチェックすることが出来る。
iモードIDの取得周りについて
何かと問題になっているiモードIDの取得はdocomoの提供するAPIにhttpsでopenid.identityとopenid.response_nonceを渡すことで取得できる。これが独自プロトコルになっているのは信用できない経路でiモードIDが流れるのを避けたいからでしょう。
OpenIDは利用者のブラウザで、OPとRP間をリダイレクトすることによって値が受け渡されるわけなので、利用者が使っている回線が盗聴されているとか怪しいプロキシサーバー使ってるとかの場合は、openid.*なパラメータは第三者が窃取することが出来てしまう。
RP側がHTTPSを使っていない、かつ、利用者の使っている回線が信頼できない、というケースを想定する。
このケースにおいてのiモードIDの取得はどこまで保護されるのだろうか。docomoの資料には「セキュリティ上の理由から1回限り有効な値となります。また、発行してから一定時間経過した場合も無効となりますのでご注意ください。」とある。つまりRPが責任を持って取得してやれば通信経路で漏れていた場合でも、第三者からの取得を防げるということだ。逆に言うとRPが取得してくれないと一定期間は第三者が取得可能な状態になる。
通信経路で漏洩したopenid.identityとopenid.response_nonceを使ってiモードIDを取得する行為は不正アクセスに該当するのかどうか？もし不正アクセスに当たるのであれば、技術的な対策は不完全だけど法的抑止力があるのでオッケーという立場も勿論あるので(世の中大体そうなってる)、それほど大きな問題では無いかもしれない。
DoCoMoの携帯持ってないんで実際に試したわけではないです。資料見る限りそんな感じです、という話。
まとめ
docomoのOpenIDの実装周りについて - 金利0無利息キャッシング – キャッシングできます - subtech
期待されていたものが発表されたが、実装の敷居が少々高いですね。
ただ便利なものなので上手く使ってみたいと思います。
