OpenID AXによるYahoo!プロフィール情報の取得
「mixiのOpenIDを使うとニックネームが取れるのにYahoo!だと何で取れないの？ムキー」って言う人もこれで安心ですね！ サンプル 前回はサンプルコードをPHPで作成しましたが、今回はPythonのWebフレームワークであるDjangoを用いて作成します。 Djangoを使ってOpenIDを扱うにはdjango-openidやDjango-Socialauthといったライブラリがありますが、今回はYahoo!Incが提供するライブラリ 2 を元に実際に動かせるサンプルを作成しました。以下からダウンロードできます。 ZIPファイルダウンロード(26KB)（提供終了） 動かしてみる 以下のサンプルは以下のような環境で動作確認を行いました。 Python2.6.5 Django1.1 SQLite3 これらのインストールは完了しているものとして今回は話を進めさせていただきます。 サンプルの
OpenID v.s. OAuth
巷間よくOpenIDは認証、OAuthは認可というようなことが言われる。もともとは、アメリカのOAuth関係者が言い始めたことである。 もちろん間違いである。 これは、OpenIDとOAuthのシーケンス、特に OpenID の Artifact Binding と OAuth のを比べてみるとよくわかる。すぐ分かるように、これらはほとんど同じである。違いは、 OAuth では、Consumer Key と Consumer Secret を取得する。OpenIDでは、Consumer Key にあたるのは realm, Consumer Secret にあたるものは、Association として、動的取得される。 OAuth で使う Identity は、当該 Service Provider にユーザーが登録した Identity である。OpenIDでは、ユーザーが選んだ Iden
仕様から学ぶOpenIDのキホン － ＠IT
にわかに注目を集めている、URLをIDとして利用する認証プロトコル、OpenID。本連載ではこのプロトコルの仕組みを技術的に解説するとともに、OpenIDが今後どのように活用されていくのかを紹介する（編集部） OpenIDってなんだろう？ 現在、国内外でにわかに注目されつつあるOpenIDという仕組みを聞いたことがあるでしょうか？ これはユーザー中心の分散ID認証システムですが、まだ日本での普及は進んでいない状況です。 これにはいくつか原因が挙げられるでしょうが、筆者はOpenIDが正しく理解されていないことが原因だと考えます。 本連載ではOpenIDの現行仕様、およびその拡張仕様とともに、実装を例に取りつつOpenIDとは何かということを明らかにしていきます。最終的にはOpenIDが切り開く未来を見るため、現在策定中の次期仕様についても触れていきたいと思います。 広がりつつあるブラウザベ
koress.jp: OpenIDの襲来に備えよ！
追記: OpenID対応サービスまとめを作りました。 たぶん、2008年のインターネット（Webサービス)業界はOpenIDによるWebサービスのID体系の統一の荒波に揉まれることになると思う。日本のサービスプロバイダは、OpenIDの襲来に備えるべき。 海の向こうではすでにDigg, Wikipedia, Yahoo, Microsoftなどが導入や支持を発表しているほか、多くの小さなネットサービスはOpenIDに頼ったアーリーアダプタの取り込みに積極的になってる。日本国内ではどうかと言えば、niftyのaboutmeなどを除いて大手のWebサービスは未だ様子を見ている状態。リサーチレベルでは重要性が把握されつつある一方、経営レベルでは「なにそれ」的な状態が多そう。いかん、いかんよ。 2008年、YahooかAmazonかGoogleかわからないけれど、ほぼ間違いなくどこかの日本の大手の
OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入！話はそれからだ - 日向夏特殊応援部隊
やっと下準備終わったので書いてみる。 OpenID でのプトロコルメッセージで、認証アサーション要求*1及び応答*2でのメッセージは通常、RP-OP 間で associate 時に交換した MAC キーを持って署名を行う為、期待する相手と通信している限りは改ざんは起こりにくいと考えられます。 但し最近話題に出て来ている DNS Cache Poisoning のような攻撃を受けた場合、中間者攻撃 (man-in-the-middle attack) が成立する可能性があります。 攻撃手法の例 例えば、RP の DNS が汚染されていた場合を考えます。本来 OP であるはずのホストが悪意のある第三者のサーバーに割り当てられていた場合、その第三者のサーバーが中継を行えば、DH 鍵交換を行ってもまったく無意味で、認証データが盗まれる可能性があります。つまり、 RP から見ると OP に見えて O
OpenIDにフィッシングの危険発覚
DNSキャッシュポイズニングの脆弱性の影響で、「OpenID」の認証システムが危険にさらされているという。 最近問題になっているDNSキャッシュポイズニングの脆弱性に関連して、シングルサインオンに使われる認証システム「OpenID」の弱点が指摘されている。 Sun Microsystemsのロビン・ウィルトン氏は、ブログでこの問題について解説。OpenIDはDNSシステムに依存しているため、根幹となるDNSインフラがキャッシュポイズニング攻撃を受けると、OpenIDの発行や認証を担う「OpenIDプロバイダー」（OP）と、OpenID対応サイトの「Relying Parties」（RP）の間で正規サイトと偽サイトの区別ができなくなるだろうと指摘した。 Googleのセキュリティ担当者ベン・ローリー氏とケンブリッジ大学の研究者リチャード・クレイトン氏も、この問題についてアドバイザリーを公開し
XRI vs URI - 日向夏特殊応援部隊
これ実は最近のホットな話題みたいですね。 O'Reilly Media - Technology and Business Training XRI vs. URI? がニュース系の記事で、 W3C TAG Questions on Draft #2 of XRI Resolution V 2.0 from noah_mendelsohn@us.ibm.com on 2008-02-01 (www-tag@w3.org from February 2008) TAG recommends against XRI from Williams, Stuart (HP Labs, Bristol) on 2008-05-21 (www-tag@w3.org from May 2008) ここらへんが W3C TAG の意見。 =nat さんの反論はこちら 今朝久しぶりに… | @_Nat Zon
Re:OpenID再利用問題 - 日向夏特殊応援部隊
Young risk taker.: OpenID再利用問題 この話は非常に興味深いですね。 もしも、私達が利用しているOpenIDプロバイダがドメインの更新を忘れて、第三者にドメインが取得された場合、私達のアカウントがこの第三者により不正に使用される可能性が出てくる。 事業者としてやりきる覚悟が無いならば OpenID Provider にはなって欲しくないし、まぁさすがに全うなネット事業者ならまずそういう事はあり得ないとは思いますけど。 ユーザは、セキュリティ的、高可用性の両方の側面からRelying Partyでのユーザ登録に、OP-Local Identifierを使用すべきではない。 言わんとしている内容は理解出来ますが、普及の点からすれば多くのユーザーは自分のドメインでdelegateしているなんて考えにくく OP-Local Identifier をそのまま使っているであろう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
