GINZA TECH LOUNGE feat. OpenID

GINZA TECH LOUNGE feat. OpenIDに参加中。 こんなに濃いイベントなのに120名もの参加者。ちゃんと参加早々にほぼ満席になってる。 リアルタイムで更新してみるよ。

Yahoo! Japan

Open化戦略の一環としてOpenIDに対応。 開発は4人で1.5月。米Y!との同時リリース！

OpenIDからは、Yahoo! JapanのIDが分からないようにランダムな文字列になってる。 Yahoo! Japan のIDはオークションなどでも使われているので、外には出したくないみたい。 ただし、OpenID2.0に対応しているので、利用者はIDを覚えなくてよい、と。

OpenIDを使うためには、ユーザが明示的に初期設定する仕様にしている。 これは、Yahoo!のIDを大量取得者がいるためで、RPを不正に利用することを防止するため。 初期設定時にCAPTCHAを使ってbotによる自動登録を防止している。

認証するときは、まず利用者がOP Identifier URLを入力する。 ここで、yahoo.co.jp だけでなく yahoo.jp でもOKってのは知らなかった。

ここから箇条書き…。

• アソシエーションはHMAC-SHA1。SHA256にはいずれ対応する。
• checkid_immediateモードには非対応（mixiは可能している）
  • ログイン時にユーザの同意を必須としたいかららしい。
• RPのDiscovery（RPの存在チェック）
  • 本家のYahoo!はRP Discoveryに対応していない場合に警告を表示する仕様
  • 日本はDiscoveryをやってるけど、警告はなし。RPの対応状況を見ながら決めるみたい。
• セキュリティ対策
  • 認証前のログインシールと認証後のログイン履歴チェック。
  • 認証結果の送信時にIDの再利用問題への対策として、IDにフラグメントを付与している
  • あんしんネットで利用しているブラックリストを利用

属性情報には非対応。 要望は認識していて、ソーシャルプロフィールとの連携を検討中。 PAPEに対応予定と。

利用者が途中でログインをやめた場合には、RPへ否定アサーションを返すのではなく、Yahoo! Japanのトップへ移動する。 これは、RPが否定アサーションに対応していなかった場合に無限ループするかも？というのが理由。

ログイン時に他人のClaimed Identifierを入力した場合は、エラーにせずに本人のIDを返す仕様。 RPは認証結果を受け取ったときにClaimed IDでDiscoveryしてね、と。

開発時に苦労した点は、動かないときにライブラリのバグか自分のバグかわかんない。

RPはiknow.co.jpが圧倒的に多いと。 これは分かっていたことだけど、OpenIDではOPである Yahoo! Japanが「誰がいつどのサービスを使ったか」という情報を握れるね。 今後は、属性情報の提供を検討中。ソーシャルプロフィールやReputationに使える情報（優良ユーザ）の提供を検討。

会場からはIDのエイリアスに対応して欲しいという質問が。 RPが増えたら考えるとのこと。今は属性情報の受け渡しを優先したいと。 「OAuthなどのAPI連携の絡み」という話があったけどよく分かんなかった。

mixi

Yahoo! Japan が OpenID と Yahoo! の ID を結びつけないようにしているのに対して、 mixi は「アイデンティティとしてのURL」を重視しているのが対照的だった。 たとえば、以下のようなURLをOpenIDとして使える。

https://id.mixi.jp/asannou

URLをクリックすると、そのユーザのmixiページへリダイレクトされる仕様になってる。 プレミアム会員限定だけど、確かにこのためだけにプレミアム会員になってもいいかもと思った。

最初に、mixiのOpenIDでログインできるRPの一覧が紹介されていた。 思った以上にRPが増えている印象。mixiが対応したことをきっかけに、普及の壁を超えた印象。

OpenIDの1.1と2.0のどちらにも対応。1.1しか使えないRPもあるからとのこと。 OpenIDの役割は (1) シングルサインオン と (2) アイデンティティの証明 の2つ。 SNSはアイデンティティのかたまりなので、(2)を重視しているみたい。 URLを公開するかどうかは、RPにコントロールさせるべきというポリシー。 ただ、SSOだけでいいっていうニーズも認識していて、 mixiのアイデンティティと切り離されたIdentifierも検討中。 RPごとに別々のIDを発行して名寄せを防止する仕様にしたい。

次は、OpenIDの属性交換について。 mixiのニックネームをRPに渡せるようにしてみた。AX。SREGに対応。 さらに、独自仕様としてマイミク認証やコミュニティ認証が可能。 これは、OpenID Membership Authとして、標準化を目指して活動していく予定とのこと。 直感的には流行りそうなんだけど、どうだろう。 ちなみに、18歳以上の認証にも使えるよ！

「常に同意」ボタンがあるよ。mixi.jpでログインできるよ。

セキュリティ対策

• DNS cache poisoning
• phsing

OPがすべきこと

• OP EndpointをSSL/TLSで提供
• Identifier / OP Identifierも同様
• フィッシング対策の啓蒙
• mixiもRP Discoveryを実施→ログを残す程度。画面に出さない。

RPがすべきこと

• SSLの正しい利用（証明書チェック）
• RP Discoveryへの対応

今後

• マイミクのマイミク認証
• AXの拡張。プロフィール画像とか。

Q&A

• すでに会員登録機能を持つRPへの訴求点
  • → 有名人（mixiやはてな）、ソーシャルグラフの取り込み
  • → ミクシは平均21人のマイミク: 1人がRPサービスについての日記を書けば21人への口コミ効果
  • OpenID対応でユーザ数が2倍になったサービスもある

ATND

やっぱり箇条書きで。

• ログインはOpenIDのみ。チャレンジ！
• Railsを使っている。
  • ruby-openidライブラリとopen_id_authentication。
  • restful_authenticationも。
  • ユーザテーブルにはニックネームとidentity_urlを保存。どっちもユニークに。
  • 「今すぐ使えるOpenID」を宣伝してくれた！

新規ユーザ登録

• ユーザ名の取得 … SREGを使ってnicknameがあれば利用。なければidentity_urlを使う。

困ったことは、ユーザ名（ニックネーム）を決める方法。

• 反省点…identifier_urlをニックネームにするのはやめたほうがいい。
• ユーザ名がユニークにしたいが、OpenIDで取得したnicknameは重複する可能性がある
• IDの重複でエラーを出したくなかったので、identifier_urlをデフォルトに
• でも、他のサイトはそこまでやってない
  • iKnowはユーザ名が重複していたら警告を出すくらいの実装

OpenIDを認知してもらうこと

• できるかぎりOpenIDという言葉を使わない
• idselector.com→ OpenIDの入力を補助
• OPを絞る
• checkid_immidiateを使う

RPが増えていく中で、ベストプラクティスが見つかる。 「白鳥のように裏で頑張って、表は簡単に」。

質疑応答

• 複数のOpenIDを持っているユーザ向けに、ユーザIDのひも付けをRPでやるか？ → RPごとにやるのは大変。もっと下のレイヤーでやれるといいね。
• イベント画面ではニックネームだけを表示。OpenIDのURLを出さないのは意図している訳じゃないみたい。

ライトニングトーク

ゆーすけべーさんのListPod。

• OpenIDアカウントのみでログイン。OpenIDがなければ成り立たなかったサービス。
• 利用者はyahoo.co.jpがダントツ。2位がはてな。mixi対応前にリリースしたのでmixiユーザは2人。
• 携帯対応ができない。
• どのOPでユーザ登録したのか忘れたりする。
• OpenIDってアダルトサイトで使えるの？

FlipClipさん

• OpenIDでログイン後、ローカルのIDとひも付ける方式。fastladderと同じ方式か。
• ミクシがOpenID対応。今なら対応サイトとして宣伝してくれる！
  • mixiのお知らせに掲載されてユーザ数が増加！
• 意外とID忘れの問い合わせは減らない。
• 使ってみると便利という声。

okyuu.com

• 2.0対応のOPが少ない
  • 1.1対応のためにOPを絞ってリストボックスから選択して入力の手間を省く
• sxipper対応で工夫したよ

感想

やっぱり、実際の利用例を聞くと、頭の中の考えがまとまるよ。 ためになったイベントでした。

ローカルIDとの統合とか、OpenIDのアカウントを忘れた場合とか、そういう運用上の課題がでてくるけど、それは時間が解決するのかも。