「JugemKey認証API」を公開しました
でついに、JugemもAPIの公開に対応。
さっそく試してみました。すでにTypekey,Flickr,Hatenaはためしたことが有ったのでJugemもさくっと対応できました。
基本的にはFlickrと同じ方式ですね。
■良いところ
PHP,Perlのモジュールが公開されている。（PHPのライセンスが不明？ＰＨＰなのでＰＨＰライセンスというｋととで良いのだろうか？ＧＰＬだったりすると怖い・・・）
比較的簡単に実装できる。
ログインしてもらう側のシグネチャの実装が違うときに違うけど、それでもログインする？と出る。
これはユーザにとっては良いのか悪いのか賛否両論ありますが、いろいろ情報を出してユーザにゆだねるというのは１つの方式としてアリだと思います。
■微妙
call_back_urをurlエンコードしてくださいの記述があるが、
ダイジェスト化するときには、エンコード前なのかエンコード後なのか一瞬迷う。
(当然、前です。)
■悪いところ
サービスサーバーから、Jugemサーバに確認のアクセスを出す形なので
１．Jugemからのレスポンスが重いかったり落ちていたときに、サービスサーバがDOSを食らった時の 回避コードの記述が大変
２．不正なコールバックを防ぐために、call_back_urlなどを工夫して独自の認証を入れないと 正規にコールバックされたものなのか、いきなり、call_back_urlを直で呼ばれたのかがわからない。 認証自体はNGになるのでよいが、都度Jugemに確認しに行かざるを得ないのでDOSの可能性
なので、回避のためにCallBackの正当性確認のため、やっぱりコードが大変
☆結局のところ
Flickr類似方式にはすべて言えるのですが、
ログインされるサーバから、認証サーバにパスを張らないといけないので
このトラヒックがボトルネックになりやすいという事です。
認証サーバが落ちていた、重かった時に、回避しなかったりしないといけない。
☆自前で認証後のコールバックの正当性を確認しないといけない
なんらかの方法で、自分が発行した認証依頼がコールバックしてきた事を確認しないと
いきなりＣａｌｌＢａｃｋＵＲＬへ来た場合に、はじけない（上記トラヒック問題のため弾きたい）
ので結局Ｔｙｐｅｋｅｙと同じように認証は必要。
☆というわけで、 軽く作るなら、Ｆｌｉｃｋｒ方式の方が楽なのですが・・・
セキュリティ的にＤＯＳまでふまえると結局認証とか輻輳制御を入れないといけないＦｌｉｃｋｒ＆はてな＆Jugem方式の方が実は最終的には大変で、Ｔｙｐｅｋｅｙ方式の方が認証を受ける方は楽なのではないかと思ったりしてますが、時代はＦｌｉｃｋｒ＆はてな＆Jugem方式に流れていくのでしょうがか？公開鍵暗号化方式とか、いいと思うんですがねぇ・・・ＣＰＵが重いのが良いか、ネットワークが重いのが良いか？
まぁ、そんなゴリゴリしたアプリケーションの場合は自前でアカウント対応しろって？
まぁ、その通りだっorz
