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とパスワードを教えてあげないといけない。
一方、 flickr の認証APIを自分のWebアプリに組み込んだ場合は、利用者が認証APIを使ってログインするとWebアプリへ「トークン」が送られる。 このトークンを使うと、利用者の写真を取得・更新することができる。 もちろん、利用者は勝手に自分の写真を変更されては困るので、Webアプリごとに許可する権限を制御できるようになっている。 このWebアプリには取得だけ、こっちは更新もOKという感じで*1。
つまり、はてな認証APIは「認証」だけのAPIなのに対し、Flickr APIは「認証」と「アクセス制御」のAPIを兼ねている。 ちなみにここまでの話は、奥 一穂さんがWEB+DB PressのVol.34号に寄稿した「認証API最前線」の記事が参考になる。 ちなみに僕も同じ号ではてな認証APIの使い方の記事を書かせていただいた。 今ならhttps://www.amazon.co.jp/dp/4774130729がお買い得かな。
これだけみると 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）」って何が違う？）。