UK STUDIO - OAuthを使ってみた雑感
最近、TwitterのDMスパムなどで話題のOAuthですが、仕事で使ってみて色々思うところもあるのでまとめておく。 OAuthは安全か まず、 OAuthでよく言われてるようにみえるパスワードをサービスに渡さないから安全ということに関して。簡単に言うと、「パスワード渡すよりは安全だけどまぁ信用していいかどうかの判断は必要だよね」ってところ。 OAuthは難しい話を抜きにしてしまえば、期限つきパスワード(Twitterは無期限っぽいですが)をサービスごとに発行するようなものだと思う。パスワードを渡した場合と違って、パスワードを書き換えられてログインできなくなるということはないが、APIで実行できることは基本的に出来るのでOAuthにもそれなりのリスクはある。 リスクと言ってもパスワードを第三者に渡すよりははるかに安全。先程述べたようにパスワードを書き換えられる心配もないし、仮に第三者のサ
Outbound OAuthを実現するOAuth Proxy - Codin’ In The Free World
OAuthプロトコル上でのプレイヤー数について 三者間のやりとり OAuthは基本的に、サービスプロバイダ、コンシューマ、エンドユーザの、 三者間でのやりとりのためのプロトコルです。(3-leggedと呼ばれます。) 二者間でのやりとり また、サービスプロバイダとコンシューマがダイレクトにやり取りを行う OAuth Consumer Requestという拡張仕様もあります。(こちらは2-legged OAuthと呼ばれます。)トークンを使わずに署名だけでやり取りを行います。 元々は、コンシューマが、エンドユーザーでなく自分自身のデータを取得 したいときに利用されるためのものでしたが、OpenSocialにおいて、複雑な やり取りを行うときに、エンドユーザーの混乱を防ぐために用いられるシーン があります。こちらについては後日説明します。 その他 OAuthのプロトコルでは、上に挙げた、3-l
OpenIDとOAuthを同時に扱う拡張仕様 OpenID OAuth Extension - Codin’ In The Free World
あるサービスプロバイダが、OpenID、OAuthを利用したデータの提供の両方に対応している場合、 そのどちらもRP,Consumerとして利用したいというサービスがあった場合、OpenIDのために、 エンドユーザーをOPにリダイレクト、そしてまた、データを取得するAPIを叩きたいときに、 OAuthのフローに従って、エンドユーザーがプロバイダにリダイレクトさせて認可を求めなければ なりません。 二つの異なるプロトコルで、共にエンドユーザーの承認を求める画面出すこのフローは、 エンドユーザーを混乱させるものになります。 「なんで何回も飛ばすんだ。まとめて一度に認証させればいいだろ。」ってことですね。 それを可能にするためのOpenIDの拡張仕様として提案されているのが、 OpenID OAuth Extensionのようです。 http://step2.googlecode.com/svn
OAuth Core 1.0
This specification was obsoleted by OAuth Core 1.0 Revision A on June 24th, 2009 to address a session fixation attack. The OAuth Core 1.0 Revision A specification is being obsoleted by the proposed IETF draft draft-hammer-oauth. The draft is currently pending IESG approval before publication as an RFC. Implementers should use RFC 6749: The OAuth 2.0 Authorization Framework instead of this specif
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
まちゅダイアリー - OAuth Core 1.0 がリリース, "Your Valet Key for the Web" , OAuth の Rails 実装 (oauth-plugin, oauth4r) を使ってみた
