«前の日記(2007-09-24 (月)) 最新 次の日記(2007-09-26 (水))»  

まちゅダイアリー


2007-09-25 (火)

WebAPI のアクセス制御に使える OAuth という仕様

miyagawa さんの Twitter で知ったけど、 OAuth という仕様が公開された。 日本語の情報は、OAuth - リソースへのアクセスを代行するプロトコルに、詳しいメモが書かれている。仕事が速いなぁ…。

OAuth は,第三者に対して,認証を要求するリソースへのアクセスを一時的に許可するためのプロトコルです.

たとえば,写真印刷サービスがあるとします.そして,あなたは flickr に保存してある非公開写真の印刷を依頼しようとしています.このとき,写真を "公開" 状態にすることなく,また flickr へのログイン情報を教えることもなく,印刷を依頼することができます.

面白そうな仕様なので、ちょっと整理してみよう。 OAuthのメーリングリストなどは全然読んでいないので、勘違いがあるかもしれない。

OpenID が認証のための仕様だとすると、 OAuth はアクセス制御のための仕様っぽい。 認証とアクセス制御の違いが紛らわしいので、昔の日記に書いた「はてな認証API」と「Flickr API」を例に考えてみよう。

例えば、自分で作ったWebアプリに「はてな認証API」を組み込むとする。 アプリの利用者が「はてな認証API」を使ってログインすると、Webアプリ側には利用者のはてなidが送られる。 もちろん、はてなにログインするためのパスワードは、Webアプリには送られない。 このとき、Webアプリは利用者のはてなidを知ることができるけど、利用者の代わりにはてなダイアリーを書いたり、はてなブックマークを追加したりはできない。 「はてな認証API」を作った id:naoyaのはてなダイアリーにも、以下のように書かれている。

とりあえずは、はてなのアカウント名を外のアプリケーションで使える、というところまでできるようにしました。Flickr API とかだと、ここでトークンが取得できてさらにそのトークンを使って写真を投稿したりプライベートな写真を取ったりいろいろできるのですが、その辺はおいおい。

現状では、Webアプリ経由ではてなブックマークを更新しようと思ったら、はてなブックマークAtomAPIを使う必要がある(はてなダイアリーを更新するAPIは知らない)。 AtomAPIではWSSE認証というのを使っていて、リクエストのHTTPヘッダにはてなidとパスワードを埋め込むようになっている。

X-WSSE: UsernameToken Username="hatena", PasswordDigest="ZCNaK2jrXr4+zsCaYK/YLUxImZU=", Nonce="Uh95NQlviNpJQR1MmML+zq6pFxE=", Created="2005-01-18T03:20:15Z"

なので、利用者はWebアプリにはてなidとパスワードを教えてあげないといけない。

auth with password

一方、 flickr の認証APIを自分のWebアプリに組み込んだ場合は、利用者が認証APIを使ってログインするとWebアプリへ「トークン」が送られる。 このトークンを使うと、利用者の写真を取得・更新することができる。 もちろん、利用者は勝手に自分の写真を変更されては困るので、Webアプリごとに許可する権限を制御できるようになっている。 このWebアプリには取得だけ、こっちは更新もOKという感じで*1

flickr (1)

つまり、はてな認証APIは「認証」だけのAPIなのに対し、Flickr APIは「認証」と「アクセス制御」のAPIを兼ねている。 ちなみにここまでの話は、奥 一穂さんがWEB+DB PressのVol.34号に寄稿した「認証API最前線」の記事が参考になる。 ちなみに僕も同じ号ではてな認証APIの使い方の記事を書かせていただいた。 今なら WEB+DB PRESS 総集編 [Vol.1~36](WEB+DB PRESS 編集部)がお買い得かな。

これだけみると Flickr API のほうがいいじゃんって思うけど、必ずしもそうとは限らない。 Flickr API だと、「認証」と「アクセス制御」の仕組みが一緒になっているので、認証だけに使いたい場合でもそのWebアプリが利用者のプライベートな写真も見ることができちゃう。 それに、Flickrの独自の仕様なので、サービスごとに仕組みが異なってしまうし、OpenIDなどの認証と併用することもできない。 逆に Flickr API のメリットは、「認証」と「アクセス制御」を一緒に提供することで仕組みをシンプルにしていることかな。

というわけで OAuth

OAuth は「アクセス制御」だけの仕組みを提供するようになってる。 認証は普通のフォーム認証やはてな認証APIやOpenIDなど好きな方法を使えばよくて、データを更新するためのトークンの要求〜取得の仕組みだけを決めましょうということ。 「認証」と「アクセス制御」を分けることで、より広い用途に使ってもらえると考えているんじゃないかなぁ。推測だけどね。

どっちにしても、Twitter APIのようにidとパスワードをそのままWebアプリに渡すような仕組みはマズい*2訳で、こうやって安全な仕組みが提案されるのはいいことだと思う。「WebAPI で AtomPub を標準に」といっても、Basic認証やWSSE認証を使ってちゃダメじゃんって思っていたので、OAuthの今後が楽しみ。 はてなや Twitter が採用するといいなぁ。Twitterの中の人が執筆者に入っているみたいだけど。

最後に妄想。 はてな認証APIで利用者を認証し、はてなスターのお気に入りAPIでFriendを取得し、Friendだけに利用者の情報を見せるようなWebAPIを作ると面白いかもね。 「認証」+「評価」+「アクセス制御」。

似たような仕組み

ついでにメモ。 OAuthに似たような仕組みがすでにいくつか提案されてる。比較してみると面白いかも。

追記

分かりやすく「認証」と「アクセス制御」って書いたけど、一般的には「認証 (Authentication)」と「認可 (Authorization)」と呼ぶみたい。認可は承認や許可と呼ぶこともある(参考: 「認証(Authentication)」と「認可(Authorize)」って何が違う?)。

*1 厳密にはWebアプリ側が取得・更新・削除のいずれかを要求して、利用者はそれにOK/NGを返すようになってる

*2 movatwitterのような第三者アプリを経由する場合ね。利用者のクライアントアプリからAPIを使う場合は除く。