naoyaの日記

■ 認証API周り 11:34

いろいろフィードバックをもらったのでやること。

1. はてなははてな以外のサイトではパスワードは要求しませんというのをヘルプに記載しつつ、認証API以外のところでも言及する。
2. 絵を描く。d:id:hyuki さんがシーケンス図を書いてくれてるけれども。これ使わせてもらおうかな。
3. サンプルアプリケーションのコードをヘルプに掲載する。
4. 認証画面にもう少し「これは何」という文章を追加する。
5. 認証画面にコールバックURIも掲載する。

上記以外のトピック

まずトークンの話。

fumiakiy 『> 名前を使うだけでもトークンって必要になるのかな。あんまり直接的考察ではないんですが。認証の結果として即ユーザー情報が来てしまうと、それを保持しておく以外にないので、いったん許可したユーザー情報をいつまでもとっておけるように錯覚してしまいます。トークンが返ってきて、そのトークンで改めてアクセスしてやっとユーザー情報が取れるという場合、トークンでアクセスしてユーザー情報を取るという処理を繰り返すことができるので、ユーザーがはてな上で許可を取り消した場合に気づきやすいです。確かにいずれにしてもユーザー情報が取れてしまう以上、それをいつまでも保持してしまうアプリケーションを防ぐことはできませんが、なんというか発想の問題。「あなたのトークンしか保持しませんよ」という宣言をして少しでも信用度をあげたいアプリケーションを許してくれないというか。ところで受け取ったユーザー情報っていつまで保持してていいんでしょうか？はてな上で拒否されたかどうかを定期的に確認することはやっぱ義務付けたほうがいいような気がしますけど。悪意の実装を防げないからといって善意の実装と悪意の実装の区別がつきにくいのはいいことではないというか。』(2006/04/25 09:06)

naoyaグループ - naoyaの日記

という話なんだけど、昨日 IRC でいろいろ話を聞いたのも合わせるとトークンを用意するための目的は以下のものがありそう。だいたい5つくらいか。

• ステートレスな環境でも使えるように、認証情報を cert なしで再取得できるように
• 例えばメールアドレス(これは公開することはない。あくまで例え話。)のようにユーザーが後から変更できるパラメータを、アプリケーションから再取得したいとき用
• ローカルに情報をいろいろキャッシュしなくていいように。
• このコメントであるように定期的な確認を義務づけるため(ユーザーが認証許可を破棄したことを定期的に確認させるため)
• トークンを発行してはてなの他サービスのAPIと連携させる(例えば AtomPP の認証をトークン + api_key で突破できるとか)

なんだけども、現状トークンを導入するに至ってない理由として、いま返却してる情報がすべて、はてなにいる限り半永久的に固定された値だというのがあります。ユーザー名とプロフィール画像のURLはずっと固定。なので上記のうち 2番目の用途にはまだトークンはいらない。一番最後のも、まだ他サービスのAPIとの連携が実現できてないので保留。

で、3番目のローカルにキャッシュしなくていいように、だけれどもおそらくどんなアプリケーションでも認証管理をするならユーザー名はローカルにキャッシュされる思われるのと、あと画像を表示したい場合に都度認証APIを叩くなんてこともあり得なそうなのでこれもキャッシュされそう。なのでこの線も現時点では消える。

4番目の定期的な確認というのは、2番目のそれがないと確認しにいくインセンティブがない。毎回同じ情報が返されるのが分かってるのに確認しにくるアプリケーションを作ってもらうというのは微妙。

というわけで残るのは 1. なんだけど、1 の用途で使われるものがあまり想像できてない。ということで全部消えて、現時点でトークンで認証するエンドポイントを作るのはちょっと冗長な感じが否めない。

が、トークンを発行して定期的にチェックしにきてもらい、その結果として許可を破棄されたとかそういう情報を受け取ってもらうというのは是非そうしたいと思ったので、結論としてははてなに定期的に情報を取りにきてもらったりする必要があるデータを吐き出して、それをインセンティブにトークンの実装としたいなあと思ってます。はてな市民であるかどうかとか、各サービスの利用状況とかそういう情報を返すエンドポイントを作って、という感じですか。そのエンドポイントでは今認証情報の後に返してる情報も一緒に返すと。

もう一つははてなブックマークの AtomPP の認証を api_key + トークンで突破できるようなことを実装する。するとトークンは必ず必要になる。

と、この二本立てでいきたい。元々トークンはいずれかの段階で実装する予定で、返却フォーマットもそのつもりで設計してあります。

話は変わって、もう一つはコールバックURLで悪さが云々という話。

現時点ではコールバックURLは公開されてなくてそれが不安だという声があるのでそれは公開するとして。でもコールバックURLの中で何をどう実装するかとか、後からその実装を変更するとかでいくらでも悪意のある実装はできる。

で、これが脆弱性かというと脆弱性ではないよね。例えば blog への投稿を肩代わりするアプリケーションで、その blog のアカウント名/パスワードを要求するサイトって色々あると思うんだけど(それがいけてないからこその認証APIなんだけど)、そのサイトを信頼して情報を預けて、後からそのサイトの中の人がごちゃごちゃやった場合とかアカウント/パスワードを管理してるサイトが脆弱だってはならないというのと一緒の話かと思う。

あと実際問題として、いまコールバックURLの中で何か悪事をしようと思ってもせいぜいユーザ名が取れるぐらいで、なにかすごい被害を出せるようなことはないと思う。

結城さんが言ってるようなフィッシングの話はまた別の話かな。

結局 Flickr の API を参考にしてるので、Flickr API で問題とされてないところは同じく問題にならない可能性も高く、逆に向こうで問題になってることはこっちでも問題になり得るというところだなあ。で実装の違いとしてトークンのところをまだはてな側では実装してなくって、いま色々要望がきてるのはその辺と。

Flickr API のセキュリティ的なリスクみたいなのに詳しく言及してるサイトとか知ってたら教えてください。