FAQ
mixi OpenID とはなんですか?
mixi OpenID は mixi 内で築かれたユーザー同士の関係や、コミュニティへの所属情報などを、OpenID 2.0 に基づき外部のサイトに提供する認証サービスです。
mixi OpenID では一般的な OP のような特定個人の認証だけではなく、「あるユーザーの友人である」「あるコミュニティに所属している」といった関係性を認証の手段として使用できます。
mixi Platform 利用登録は必要ですか？
mixi OpenID の利用については「mixi Platform 利用登録」は不要です。認定パートナー、一般パートナー、個人パートナー等 mixi Platform の利用に際して必要とされる各種パートナー登録なしでご利用いただけます。
ミクシィ認証でログインできる Web アプリケーションを作成する場合、どのように実装するべきでしょうか?
まず、Web アプリケーション自体が OpenID でログインできるように実装されている必要があります。
次に User-Supplied Identifier として https://mixi.jp を使用して OpenID でログインする URL を提供し、そこへのリンクをはってください。
たとえば
http://example.com/login?openid_identifier=URL
が User-Supplied Identifier として URL をとりログインする URL であれば、
<a href="http://example.com/login?openid_identifier=https://mixi.jp">ログイン</a>
のようなリンクを用意してください。
あるユーザーの友人だけがログインできる Web アプリケーションを作成する場合、どのように実装するべきでしょうか?
たとえば、あるユーザーの URL が http://mixi.jp/show_friend.pl?id=X で
http://example.com/login?openid_identifier=URL
が User-Supplied Identifier として URL をとり OpenID 仕様に基づきログインする URL であれば、まず
<a href="http://example.com/login?openid_identifier=https://id.mixi.jp/X/friends">ログイン</a>
のようなリンクを用意し、mixi.jp から返ってきた Claimed Identifier が https://id.mixi.jp/X/friends/[ユーザー ID] であることを RP 側でチェックしてください。
mixi に送信する前の User-Supplied Identifier については、RP 側で判定・処理を行う必要はありません。例えば、http://mixi.jp/show_friend.pl?id=X と https://id.mixi.jp/X/friends を同一視する処理も OP 側で行なわれます。
ユーザー ID やコミュニティ ID として数字以外の文字が出現することはありますか?
ユーザー ID には出現することがあります。mixi ではプレミアムアカウントを取得しているユーザーに対して、より分かりやすい36文字以内の英小文字・数字・アンダースコアからなるエイリアスを提供しています。
コミュニティに関しては、現在エイリアスは提供されていません。
OP Identifier として http://mixi.jp/ は使用できますか?
使用自体は可能ですが、推奨はしません。
User-Supplied Identifier として mixi.jp が渡された際、RP は http://mixi.jp に discovery を行います。こうした場合に備え mixi では http://mixi.jp, https://mixi.jp のどちらからでも OP Endpoint URL を取得できるように実装されています。
しかし、HTTP でのアクセスの場合は DNS の詐称に対して脆弱です。ミクシィでは出来るかぎり https://mixi.jp を使用することを推奨します。
RPからhttps://mixi.jp/へのSSL接続に失敗します。どんな対策が必要ですか？
多くの場合、RPのHTTPクライアントライブラリが使用しているルート証明書が古いため、OPのサーバ証明書の検証に失敗した場合にこのような現象が発生します。RPで使用しているHTTPクライアントライブラリのルート証明書を最新の状態に更新する必要があります。更新の方法は使用するクライアントライブラリによって異なりますので、詳しくはそれぞれのマニュアルを参照してください。
参考までにPHPなど広く利用されているcurlについては、"crul - Details on Server SSL Certificates"で具体的な更新手順の説明と、最新のルート証明書の取得方法について説明されています。
セキュリティ上の注意
HTTPクライアントをサーバ証明書の検証を行わないよう設定して問題を回避することは可能ですが、これはセキュリティ上非常に問題のある対応です。OPとRP自身とそれぞれのユーザーを危険にさらさないためにも、RPではサーバ証明書の検証を実施するようにお願いします。
次のような記述は、DNS詐称によるセキュリティリスクを高める悪い方法です。
# 悪いコードの例。このオプションが無指定の場合は証明書の検証が行われます
curl_setopt($c, CURLOPT_SSL_VERIFYPEER, FALSE);