TwitterのBasic認証->OAuthへの切り替えのまとめはあるでしょうか
Ryuji Kanbe
便乗して、質問させていただきます。
TwitterのBasic認証が廃止になり（延長になったようですが）、
その置き換えに悩んでいます。OAuthでよい場合もありますが、
ソーシャルアプリの内部からなどブラウザのリダイレクトが
使えない場合などは、XAuth?というものを使ったり、
Twitterにメールを送らなかったりしないといけないようです。
このあたり、誰もが困っているところだとは思うのですが、
なんかこのへんうまくまとまっている文章はあるでしょうか。
いずれやらなくてはいけないことなので、自分でもまとめようとは
思っているのですが・・・
--
神部
NAKAMURA, Hiroshi
> なんかこのへんうまくまとまっている文章はあるでしょうか。
私も知りたいです。
万が一なかったときのために、BasicAuthからの移行の方向性を
私の理解で整理してみました。追記/コメント希望。
1. ウェブサイトとして実装しているサービス
→ OAuth 1.0a
2. ケータイ向けウェブサイトとして実装しているサービス
→ xAuth(*1)
or
→ OAuth 1.0a(*2)
3. デスクトップアプリとして提供しているアプリ
→ xAuth(*3)
or
→ オープンソースの場合は、"Open Source applications using OAuth"の対応を待つ(*4)
4. ソーシャルアプリの内部ガジェット？
→ xAuth? 確かOAuth対応したOpenSocialコンテナがあったような気がしますが、
詳しいかたお願いします。
(*1) ウェブサイトでxAuthするなら、SSLでのサービス提供が必要でしょう。
(*2) OAuth 1.0aで、ブラウザからTwitterに接続させ、ユーザによる権限確認を行わせる場合、HTTPSで行う必要があります。そして現時点では、api.twitter.comが使っている証明書（ワイルドカード証明書）のせいで、おおくのガラケーでは接続できません。しかしTwitterは、HTTP（非SSL）での権限確認（場合によっては追加ログイン）を許しているようです（仕様かミスかは不明）。なので、HTTPで権限確認させてしまえばOAuth
1.0aが可能かも？（お勧めしません）
(*3) consumer keyは、作者が取得したものを気休めに難読化して配布するか、ユーザ個別に取得・設定してもらわないといけない。
(*4) http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c18ade9d86c8b239?pli=1
この機能拡張が、BasicAuth認証停止より先に提供されるかどうかは不明です。
しかし冷静に考えて、ガラケー向けおよびデスクトップアプリ向けには厳しい状態ですね。
matake@gmail
またけです。
PCだけで良ければ、warningでるけど外部リンク開いてaccess token取得して外部サーバに保存しておけば、xAuth使わなくても行けます。
でも、多分PCだけとかは、無いですよね？
mixi以外のモバイルコンテナの状況はよくわかりませんが、モバイルでは外部リンクがダメな時点でxAuthしかないですね。
でもコンテナ上でtwitterのパスワードを入力させるとか、コンテナが許してるんでしょうか？
っとおもったら、もうこのグループにyoichiroさんがいるじゃないですか！
--
Nov Matake (=nov)
http://matake.jp
http://twitter.com/nov
matake@gmail
> 3. デスクトップアプリとして提供しているアプリ
> → xAuth(*3)
> or
> → オープンソースの場合は、"Open Source applications using OAuth"の対応を待つ(*4)
xAuthの申請をしたことはないですが、xAuthはあくまでユーザにPIN code（verification code）を入力させるのが困難な場合のための方法なので、twitterにxAuth対応consumer keyを要望する（メール申込）する際に、その点をアピールしないと拒否されるかもしれません。
（きっと「すでにBasic認証時代のユーザがこれだけいる」とかあれば大丈夫だと思います）
> (*3) consumer keyは、作者が取得したものを気休めに難読化して配布するか、ユーザ個別に取得・設定してもらわないといけない。
termtterのようなオープンソースの場合は、xAuthはあきらてPIN codeベースのフローが必要です。
twitterがそのようなアプリにxAuthを許可するとは思えないし、"Open Source applications using OAuth" で取得するにせよユーザが個別に取得するにせよ、そのconsumer keyはxAuth対応していないはずなので。
> (*4) http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c18ade9d86c8b239?pli=1
> この機能拡張が、BasicAuth認証停止より先に提供されるかどうかは不明です。
"Open Source applications using OAuth" は、個人的にはワールドカップ騒動が落ち着けばすぐ出てくるのでは、と思っています。
OAuth echo同様、developerにはおそらく1ヶ月程余裕ができるかと。
> 4. ソーシャルアプリの内部ガジェット？
> → xAuth? 確かOAuth対応したOpenSocialコンテナがあったような気がしますが、
> 詳しいかたお願いします。
PCならgoo homeがOAuth Proxyになっていて、えーじさんが作ったガジェッツィというアプリが、Twitter OAuthに対応してますよ。
http://developer.home.goo.ne.jp/document/OAuthリクエスト
ただ、やっぱりモバイルのコンテナではデバイス／コンテナ共に制限が強くて、いろいろ難しいと思います。
（mixiボイスを使えば、twitterアプリはいらない！？）
> しかし冷静に考えて、ガラケー向けおよびデスクトップアプリ向けには厳しい状態ですね。
ですね。
--
Nov Matake (=nov)
http://matake.jp
http://twitter.com/nov
NAKAMURA, Hiroshi
>> 3. デスクトップアプリとして提供しているアプリ
>> → xAuth(*3)
>> or
>> → オープンソースの場合は、"Open Source applications using OAuth"の対応を待つ(*4)
>
> xAuthの申請をしたことはないですが、xAuthはあくまでユーザにPIN code（verification code）を入力させるのが困難な場合のための方法なので、twitterにxAuth対応consumer keyを要望する（メール申込）する際に、その点をアピールしないと拒否されるかもしれません。
> （きっと「すでにBasic認証時代のユーザがこれだけいる」とかあれば大丈夫だと思います）
xAuthの認可基準も、ゆれがあるのかもしれません。私がテスト用に作ったアプリは、
あっさり数日で「いいよー」てな感じで許可されました。無実績だったんですが。
ちゃんとアピールしないと通らない、という話は見かけるので、今は厳しいのかもしれませんね。
>> (*3) consumer keyは、作者が取得したものを気休めに難読化して配布するか、ユーザ個別に取得・設定してもらわないといけない。
>
> termtterのようなオープンソースの場合は、xAuthはあきらてPIN codeベースのフローが必要です。
> twitterがそのようなアプリにxAuthを許可するとは思えないし、"Open Source applications using OAuth" で取得するにせよユーザが個別に取得するにせよ、そのconsumer keyはxAuth対応していないはずなので。
すいません、ここは混乱していました。
3. デスクトップアプリとして提供しているアプリ
→ OAuth1.0a(*3)
or
→ オープンソースの場合は、"Open Source applications using OAuth"の対応を待つ(*4)
とすべきところでした。OAuthにせよ、xAuthにせよ、consumer tokenはなんとかしないといけなくて、
難読化にせよユーザ個別に取得してもらうにせよ、難しいね、と。
ただ、個人的には、xAuthはデスクトップアプリでこそ使うべきものと思っています。
生パスワードがサードパーティサイトへ流れずに済むところであればこそ、使ってもいいかな、と。
Twitterより先行してxAuthを実装した、FriendFeedもその思想でした
（あちらはそのものずばり、Installed Application向け認証、という名前です）。
とはいえ、Twitterがそのように考えているかどうかとは別で、もしかしたら
「xAuthは移行のための過渡的な措置で、どうせすぐやめる」だったりするのかも？
上記、xAuthの承認基準が揺れているのも、そういう背景があるのかな。
さらに、オープンソースかどうかと、xAuthを採用するかどうかは、リンクしていない
と思います。"Open Source applications using OAuth"が解決する問題は「アプリ作者にとって、
consumer tokenがbanされにくくなる」のみで、セキュリティには無関係、というのが、
今のところの私の理解です。
さらにさらに、OAuthをするのに、PIN codeでいくかリダイレクトでいくかは、また別の軸に
なりますね。termtterは、その気になればPIN codeではなく、普通のフローでいけるはずなので。
（ブラウザをURL指定で起動し、callback用のhttpdをテンポラリに起動する。
Google Buzzのサンプルクライアント、oacurlというJavaコマンドラインプログラムがやっています）
で、全てのデスクトップアプリがcallback用のhttpdをテンポラリ起動できるわけじゃないので、
そういう環境向けにPIN codeがあるんですよねたぶん。
と、まぁ、ごちゃごちゃ書きましたが、デスクトップアプリ向けの本命は、
"Open Source applications using OAuth"と同一の方式が、デスクトップアプリ全般に
解放されることだと思います。実現すれば、上記の検討は全部無駄。いつになるのかな。
>> 4. ソーシャルアプリの内部ガジェット？
>> → xAuth? 確かOAuth対応したOpenSocialコンテナがあったような気がしますが、
>> 詳しいかたお願いします。
>
> PCならgoo homeがOAuth Proxyになっていて、えーじさんが作ったガジェッツィというアプリが、Twitter OAuthに対応してますよ。
> http://developer.home.goo.ne.jp/document/OAuthリクエスト
>
> ただ、やっぱりモバイルのコンテナではデバイス／コンテナ共に制限が強くて、いろいろ難しいと思います。
> （mixiボイスを使えば、twitterアプリはいらない！？）
なるほどー。ありがとうございます。こちら方面は疎いので勉強になります。
モバイル向けにもコンテナがあるんですね。大変そうだ。。。
matake@gmail
> xAuthの認可基準も、ゆれがあるのかもしれません。私がテスト用に作ったアプリは、
> あっさり数日で「いいよー」てな感じで許可されました。無実績だったんですが。
> ちゃんとアピールしないと通らない、という話は見かけるので、今は厳しいのかもしれませんね。
さすがアメリカですねwww
> さらに、オープンソースかどうかと、xAuthを採用するかどうかは、リンクしていない
> と思います。"Open Source applications using OAuth"が解決する問題は「アプリ作者にとって、
> consumer tokenがbanされにくくなる」のみで、セキュリティには無関係、というのが、
> 今のところの私の理解です。
「アプリ利用者にとって、自分が悪用しない限りbanされずに済む」というのもあるのではないでしょうか。
> さらにさらに、OAuthをするのに、PIN codeでいくかリダイレクトでいくかは、また別の軸に
> なりますね。termtterは、その気になればPIN codeではなく、普通のフローでいけるはずなので。
> （ブラウザをURL指定で起動し、callback用のhttpdをテンポラリに起動する。
> Google Buzzのサンプルクライアント、oacurlというJavaコマンドラインプログラムがやっています）
oacurl、いいですよね。
少なくともaccess token取るまではtwitterでも使えたので、termtterはこれでいいのかも。
http://blog.matake.jp/archives/oacurl_twitter_oauth
> と、まぁ、ごちゃごちゃ書きましたが、デスクトップアプリ向けの本命は、
> "Open Source applications using OAuth"と同一の方式が、デスクトップアプリ全般に
> 解放されることだと思います。実現すれば、上記の検討は全部無駄。いつになるのかな。
ですよね。
> なるほどー。ありがとうございます。こちら方面は疎いので勉強になります。
> モバイル向けにもコンテナがあるんですね。大変そうだ。。。
日本の主要コンテナがDeNAとmixiとgreeなので、日本のOpenSocialはモバイルが主流ですね。
--
Nov Matake (=nov)
http://matake.jp
http://twitter.com/nov
NAKAMURA, Hiroshi
>> xAuthの認可基準も、ゆれがあるのかもしれません。私がテスト用に作ったアプリは、
>> あっさり数日で「いいよー」てな感じで許可されました。無実績だったんですが。
>> ちゃんとアピールしないと通らない、という話は見かけるので、今は厳しいのかもしれませんね。
>
> さすがアメリカですねwww
メールを見返したら、
I'm sending this mail according to
http://apiwiki.twitter.com/Twitter-REST-API-Method:-oauth-access_token-for-xAuth
I want to do xAuth by my desktop client application which utilizes Twitter API.
My Twitter account: nahi
Target application: OAuthTermtter by Asakusa.rb -
http://twitter.com/oauth_clients/details/102842
Consumer key: XXX
Let me know if some more information needed.
とか、なんともいい加減。OAuthTermtterというのは、メールする直前に登録したアプリです。
そのときはまだ実在せず。しかし数日で連絡が来ました。
http://dev.twitter.com/pages/xauth を見ると、
"xAuth provides a way for desktop and mobile applications"
とあるので、デスクトップアプリ、というのが効いたんでしょう。
>> さらに、オープンソースかどうかと、xAuthを採用するかどうかは、リンクしていない
>> と思います。"Open Source applications using OAuth"が解決する問題は「アプリ作者にとって、
>> consumer tokenがbanされにくくなる」のみで、セキュリティには無関係、というのが、
>> 今のところの私の理解です。
>
> 「アプリ利用者にとって、自分が悪用しない限りbanされずに済む」というのもあるのではないでしょうか。
確かに。巻き添えでbanされないというのは、利用者にとってもメリットですね。
>> さらにさらに、OAuthをするのに、PIN codeでいくかリダイレクトでいくかは、また別の軸に
>> なりますね。termtterは、その気になればPIN codeではなく、普通のフローでいけるはずなので。
>> （ブラウザをURL指定で起動し、callback用のhttpdをテンポラリに起動する。
>> Google Buzzのサンプルクライアント、oacurlというJavaコマンドラインプログラムがやっています）
>
> oacurl、いいですよね。
> 少なくともaccess token取るまではtwitterでも使えたので、termtterはこれでいいのかも。
> http://blog.matake.jp/archives/oacurl_twitter_oauth
おお、未チェックでした。なぜPOSTできないんでしょうね。。。
>> なるほどー。ありがとうございます。こちら方面は疎いので勉強になります。
>> モバイル向けにもコンテナがあるんですね。大変そうだ。。。
>
> 日本の主要コンテナがDeNAとmixiとgreeなので、日本のOpenSocialはモバイルが主流ですね。
なるほどー。勉強になります。