OAuthやOpenID、仕組みもよく知らずに使ってきた僕が、その最新動向に追いつくために勉強したことをまとめます。 きっかけは OpenID TechNight #7 をUstで見たことで、わからないことが山盛りだったので色々と調べてみた。 OpenID TechNight #7 : ATND 各発表のスライドへのリンクがあるよ。 キーワードとしては、OAuth 2.0、OpenID Connect、Cloud Identity、RESTful API、といったあたりについて。それぞれ基本的なことと、Ustで話されてたことをまとめる。 OAuth 2.0 OAuth 2.0でWebサービスの利用方法はどう変わるか(1/3)- @IT を先に読めばよかった。 簡単にまとめると、OAuth 1.0の問題点は3つあって。 認証と署名のプロセスが複雑 Webアプリケーション以外の利用が考慮されて
微妙に挙動が違うOpenID。 基本に忠実に動作してくれるともっと広がるのだろうけど、なかなかそうもいかないようだ。まず、どこで発行されているのかを調べることにする。 最も問題なのは、ブラウザの独自拡張を争っている時代と違うこと。「拡張」するなら基本は同じなのだが、「削られる」ので困る。 ニックネーム(半角英数)とメールアドレスはとても必要な情報だと思う。でも、ユーザが自分の意思で決めることができるにもかかわらず(適法)、出さないプロバイダがある。 だから、”OpenID”にだけ対応すればよいのに、それぞれのプロバイダにあったプログラムを作らないとならない。そこで、「セキュリティーの固いサイトこそ」、ID/メールアドレス、パスワードを他のサイトで入力させられることになる。 すべからく、セキュリティーの固いサイトほど、セキュリティーが弱くなる…。どこかのセキュリティー関連の文献にも出ていたけ
Gmail が OpenID Provider になったので、 google.com とか gmail.com とかでログインできるのかと思いきや、Yahoo! や mixi はドメイン入れれば OK だけど、Google はちょっと違うのね。 Google のエンドポイントはこちら。 https://www.google.com/accounts/o8/id (httpも可) 最低でも google.com/accounts/o8/id まで入力しないといけないので、やっぱり「Gmail アカウントでログイン」というボタンが必要か。 前後の記事へ « iPhone で iKnow! ができ トップ 未来のなでしこ Japan を応援しに »
GAEのUser APIの認証オプションに Federated Loginってのが増えた。実態はOpenIDなので、Google Appsのアカウントの認証に使ってみたのでメモ。 ログインURLの生成 url = create_login_url(federated_identity=<DOMAIN>) ドキュメントも更新されてる*1 Functions - Google App Engine - Google Code http://code.google.com/intl/en/appengine/docs/python/users/functions.html 設定を元に戻せる 以前からあった、Authentication Optionの「Google Apps」は、一度それに設定すると対象ドメインも含め二度と設定変更できない物だったが、「Federated Login」は元に戻す(
アプリケーションを作るさいにユーザ管理が面倒。またユーザにとっても一々サイト毎にユーザ名とパスワードを管理するのも面倒。OpenIDを使うとユーザ認証をgoogleなどの大手に任せられて、作る方も使う方も便利になる。常にスパマーとイタチごっこをして鍛えられているシステムに検証を任せられるってのは大きなメリットだ。django-authopenidを使うと比較的簡単にDjangoのアプリケーションをOpenID化してくれる。 ホームページはこれ。 http://bitbucket.org/benoitc/django-authopenid/ code.googleからbitbucketに移った。 インストール http://bitbucket.org/benoitc/django-authopenid/wiki/Installation 二三方法があるが、これが簡単: sudo apt-ge
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く