OpenID Extension紹介 + α
=ritou
http://d.hatena.ne.jp/ritou

自己紹介
• 名前
• Ryo Ito (id:ritou)
• アカウント
• twitter,friendfeed,hatena : ritou
• ブログ
• r-weblife http://d.hatena.ne.jp/ritou/
• 内容はOpenID/OAuthあたり
• 所属
•
• 2009年10月現在、社会人4年目

アジェンダ
• OpenID Extension紹介
• OpenID User Interface Extension
• OpenID OAuth Extension
• OAuthについて

OpenID
User Interface
Extension

OpenID UI Extension Background
• OpenID認証ではリダイレクトが使われている
• checkid_setupモード
• ログイン処理の間だけRPから離れることは良くない
• 分離されたpopup window内でAuthNフローが行われ
るとUXが改善されると”信じられている”
• OPが popupに気付けると、より最適化できる
• 画面サイズの使いわけ
• ネガティブアサーションの代わりにブラウザ閉じる

OpenID UI Extension Spec
• 内容
• Requesting Authentication in a Popup : popup
• graphical RP representation : OP画面上のRP icon
表示
• Language Preference : 言語指定

Requesting AuthN in a Popup
• checkid_setupモードのAuthN要求の際、
popupを利用する場合は以下のパラメータを
含む
• openid.ns.ui :
“http://specs.openid.net/extensions/ui/1.0”
• openid.ui.mode : “popup”

Requesting AuthN in a Popup Example – Google

AuthN Response in a Fragment（調査
•
中）
AuthN応答を受けた時のreturn_toが行う処理は重い
• まっ白な画面が表示されたり
• return_toに”#”が含まれる場合、OPは応答パラメータ
をfragment portionとして付加する
• 現在、各OPで挙動が違う。。。
• RP側でreturn_toを静的ページにしてブラウザキャッ
シュを使うことで速度が改善され、最適化される？
• 例 : jsのハンドラに引数を渡し、ブラウザを閉じるだけ？

graphical RP representation
• OPの承認/同意画面に表示するRPのアイコンを
RPが指定する場合、以下のパラメータを含む
• openid.ui.icon : “true”
• OPは画像のURLをRP Discoveryにより取得して同
意画面に表示する
– <Service xmlns="xri://$xrd*($v*2.0)">
<Type>http://specs.openid.net/extensions/ui/icon</Type>
<URI>http://consumer.example.com/images/image.jpg</URI> </Service>
• 見つからなかったらfavicon

graphical RP representation Example – Google

Language Preference
• checkid_setupモードのAuthN要求の際、RPか
らOPに対してユーザーが好む言語に関する”
ヒント”を指定
• openid.ns.ui :
"http://specs.openid.net/extensions/ui/1.0"
• openid.ui.lang : "fr-FR","fr-CA,fr-FR,en-CA“
• Tags for Identifying Languages
• http://www.ietf.org/rfc/rfc4646.txt

Language Preference Example – Yahoo!
openid.ui.lang : fr-FR openid.ui.lang : fr-FR
Login Page Consent Page

OP’s XRDS discovery document
• language preference
<Type>http://specs.openid.net/extensions/ui/1.0/lang-pref</Type>
• popup
<Type>http://specs.openid.net/extensions/ui/1.0/mode/popup</Type>
• graphical RP representation
<Type>http://specs.openid.net/extensions/ui/1.0/icon</Type>

各OPの対応状況
• Google
• popup + icon表示対応
• 画面サイズ : 450×500
• Yahoo!(米)
• popup対応してるけど、1画面に統一
• 画面サイズ : 500×500
• language preference対応

現状のまとめ
• もっと詰めるべきところがありそう
• Window Size
• Negative Assertion or Window close?
• Initiation
• OpenID Form
• OP Selector
• Others (WebFinger?)
• JPで広めるために必要なものは?
• 各OPの対応
• あふれ出る日本語の文言をどこまで抑えられるか
• BestPractice/ガイドライン？
• セキュリティ関連の啓蒙 : iframeはNG,アドレスバー出せとか

OpenID
OAuth
Extension

OpenID AuthN Flow vs OAuth AuthZ
Flow
1 1
RP Consumer
2 4 2 4
User User
3 3
OP SP

OpenID OAuth Extension
• Background
• OpenIDとOAuthのUXは似ている
• OP=SP, RP=Consumerのときは同じOP(SP)に対して
2回AuthN/AuthZ要求する必要がある
• OpenIDのAuthNリクエストにOAuthのAuthZリクエスト
を含めれば１回で済む

Hybrid Flow
RP and
•例 : OpenIDでログインしアドレス
Consumer ブックのデータをインポート
1. UserがConsumer上でイン
1 ポート先のProviderを選択
2. ConsumerがUserをProvider
にリダイレクト
5 3. UserがProvider上で
2 「Consumerにサインインする
4 こととアドレスブックのデータ
をシェアすること」について
同意
User 4. OPがClaimed IDとともにUser
をConsumerにリダイレクト
3 5. ConsumerはUserを特定しサ
インイン処理、アドレスブック
のデータインポート処理を実
行
OP and SP

OpenID OAuth Extension - Spec
• 追加された定義
• Combined Provider
• OP かつ SP : Google, MySpace, Yahoo
• Combined Consumer
• RP かつ Consumer : Plaxo, RPX使ってるとこ
• Extension Namespace
• http://specs.openid.net/extensions/oauth/1.0

OpenID OAuth Extension - Spec
• Request
• 【OpenID】AuthN Request + 【OAuth】Consumer Key
• Response
• 【OpenID】AuthN Response + 【OAuth】Request Token
• After AuthN/Z
• 【OpenID】 AuthN Responseを処理
• 【OAuth】 Access Tokenの取得
• Request Tokenと紐づくToken Secretの値は(空)
• 【OAuth】 リソースアクセス

OpenID OAuth Extension - Sequence

Usecases
• OpenID + Profile API
• OpenIDでログイン
• AXの代わりにProfile APIで属性情報を使う
• OpenID + Contact List API
• OpenIDでログイン
• Providerのアドレスブックにある友達にInvitationを送信
• OpenID + Activity Stream API
• OpenIDでログイン
• Consumer上のActivityをProviderのトラヒックに乗せる
• たくさんの人の目に止まる → Consumerへの誘導増加
• 小さなConsumerでも世界中のユーザーにアピールできる
• WhiteList対応

Screenshot : Google

Screenshot : Yahoo!

Screenshot : MySpace

OAuthについて
• OAuth for Mobile
• OAuthとOpenSocial
• OAuth Provider Request

OAuth for Mobile
• 仕様的にはOpenIDよりもMobileに適している
• 重い処理はDirect Communicationでやる
• RequestToken/OAuth Verifierを短くできればURL長も
OK
• 使いどころ
• モバイルサイトからのOAuth利用
• PC/Mobile以外のデバイスで動くConsumerの認可デ
バイスとして利用
• TV,デジタル家電,カーナビとか？
• “同意”だけMobileで
• カーナビより、テレビよりは文字入力しやすい、経験がある

OAuth :TV + Mobile flow
１．QRコード表示 ２．ログイン/同意
３．Verifier入力 4．APIアクセス

ClientApp を意識しているY!のOAuth
• User AuthZ URL
• Request Tokenパラメータは任意
• https://api.login.yahoo.com/oauth/v2/request_auth
• https://auth.login.yahoo.co.jp/oauth/v2/request_auth
• Request Token/OAuth Verifierは短め
• 手動入力を意識

OAuthとOpenSocial
• OpenSocialが流行るとOAuthも使われる
• SignedRequest = 2legged
• makeRequest = 3legged
• RESTful APIで定義されるAPIが増えるとContainer
じゃないOAuthのSPもAPIを出しやすい？
• 開発者にやさしい共通仕様
• ライブラリの充実
• ノウハウ蓄積
• SPはどうやって個性を出していけるかが勝負！

Proposal : OAuth Provider Request
• OAuthでProviderからConsumerに送られる
Requestがあってもいいのでは？
• CXの話で語られているような非同期通信
• ID状態の連携
• SP上でIDがディアクティベートされたことを通知
• 通知を受けて、Consumerはリカバリーフローを用意
• SPがConsumerのユーザーリソースにアクセス
（3legged?）
• SPに権限を与えるしくみ

OAuth Provider Request - Spec
• 既に共有しているConsumer Keyを利用
• 追加パラメータ
• xoauth_provider_key : provider識別文字列。ドメイン。
• ConsumerがProviderを一意に識別するには、(SP)-(ConsumerKey)
の組み合わせが必要
• 署名周り
• HMAC-SHAx
• OAuthと同じ
• RSA-SHAx
• generate : ProviderのPrivate Key
• validate : ProviderのPublic Key
• TBD : 3legged

ご静聴ありがとうございました
• OpenID User Interface Extension 1.0 - DRAFT 0.5
• http://svn.openid.net/repos/specifications/user_interface/
1.0/trunk/openid-user-interface-extension-1_0.html
• OpenID OAuth Extension
• http://step2.googlecode.com/svn/spec/openid_oauth_ext
ension/latest/openid_oauth_extension.html
• UX
• http://wiki.openid.net/Details-of-UX-Best-Practices-for-
OPs
• http://wiki.openid.net/Details-of-UX-Best-Practices-for-
RPs