2-legged OAuthについて調べてみました
最近Google Apps ScriptでSitesにMLの一覧を表示するというのをやってまして、その中で2-legged OAuthが出てきたのでちゃんと調べようと思っていました。そして連休中にUsing 2-legged OAuth with the Google Tasks API for Google Apps domain administrators - Google Apps Developer Blogという記事に出会いまして、ちょっと調べてみました。
2-legged OAuth
OAuthについてはJavaでTwitterのOAuthを書いてみました - n-3104の日記で調べていたのですが、要はユーザーIDとパスワードではなくトークンを利用して認証を行う仕組みです。そのOAuthにも2-legged OAuth（以下2LO）と3-legged OAuth（以下3LO）の2種類あって、Twitterの場合は3LOでした。3LOの場合はProvider、Consumer、Userの3者が登場し、ConsumerがProviderにアクセスする際にUserに認可してもらいアクセストークンをもらいます。一方、2LOの場合はUserからの認可というフローが不要になりアクセストークンも利用しません。ProviderはConsumerから発行されるConsumerKeyとConsumerSecretのみでConsumerにアクセスします。
実際に2LOによる実装という意味では、まずHTTPリクエストの中身については2-legged OAuthによるAPIアクセス mixi Developer Center (ミクシィ デベロッパーセンター)が、ソースコードという意味ではpythonで署名付きリクエストを送る(2-legged OAuth) « taichino.comが参考になります。
署名アルゴリズム
2LOについて調べていたら、OAuthの仕様について 〜署名？それっておいしいの？〜 (Yahoo! JAPAN Tech Blog)というページを見つけました。あまり意識していなかったのですが、OAuthで利用する署名アルゴリズムは3種類あるそうで、HMAC-SHA1の場合はService Provider(以後SP)側でConsumerkeyとSecret(秘密鍵)のペアをConsumerし、RSA-SHA1の場合はConsumer側で公開鍵と秘密鍵を生成し、事前に公開鍵をSPに登録しておくらしいです。
Appsの管理者向けコントロールパネルには署名をアップロードするUIがあったのですが、RSA用だと分かって納得しました。実際、OAuth: Managing the OAuth key and secret - Google Apps HelpにもRSA用と書いてありました。
Appsにおける2LO
Google Appsで2LOを行う場合、ドメインに対する2LOという扱いになりますOAuth for Google Apps domains。ドメイン単位でOAuthを利用して認証するのは良いとして、実際にリクエストを送信したユーザーを特定する必要があります。例えばGoogle Documents List APIの認証にOAuthを利用してドキュメントを新規に作成しようとし場合、ドメイン単位の認証では誰のドキュメントと作成しようとしたのか分からなくなってしまいます。そのため、Appsではxoauth_requestor_idというパラメーターにメールアドレスをつけることで、どのユーザーとしてAPIをコールしたのか指定できるようにしているようです。詳細はExample: Accessing a Google Data API feedを参照してください。最初に出てきたUsing 2-legged OAuth with Google Tasks API for Google Apps domain administratorsはこのGoogle Tasks API版の記事で、サンプルソースにおいてxoauth_requestor_idを設定していることが分かります。
