今回から始まった「ゼロから学ぶOAuth」。全4回の特集にて，これからのWebサービスを開発する上で不可欠な技術「OAuth」について取り上げます。初回は，OAuthの概念について取り上げます。

はじめに

はじめまして，iKnow!改めsmart.fmの真武です。現在smart.fmでは，OAuthやOpenID，OpenSocial，Semantic WebやActivity Streamなどといった新しい技術の導入を積極的に行いサイトを活性化させるとともに，smart.fm APIを通じて我々の技術を外部のデベロッパの方々にも提供しています。

smart.fmは日本最大のOpenID Relying Partyであるだけでなく，国内では数少ないOAuth Consumer（後述）およびOAuth Service Provider（後述）を兼ねるサービスとなっています。こういった背景のもと，今回私がOAuthについて経験してきたことを連載（全4回）させていただくことになりました。

この特集では，以下のようなOAuthに関わる幅広い内容を扱います。よろしくお願いします。

• OAuthの概念＆OAuthでできること
• OAuth Consumerの実装（入門：OAuth Access Token の取得と利用）
• OAuth Consumerの実装（応用：smart.fm APIおよびGoogle Data APIsの利用）
• OAuth Service Providerの実装

それでは，本題に入りましょう。

OAuthの概念

OAuthとは

OAuthは，以下の特徴を持つ「認可情報の委譲」のための仕様です。

• あらかじめ信頼関係を構築したサービス間で
• ユーザの同意のもとに
• セキュアにユーザの権限を受け渡しする

サービス間で認可情報を受け渡せると，あるサービスがユーザの認可のもとで別のサービスの管理する情報の取得／追加／更新／削除などを行えるようになります。OAuthに対応したサービスでは，ユーザが外部サービスにパスワードを教えることなく，認可情報の委譲が可能です。また認可情報の適用範囲を指定したり，有効期限を設定することができるため，ユーザが外部サービスにすべての権限を渡すこと無く，自分が利用したいサービスに最低限必要な権限のみを委譲することができます。そのためBasic認証と比べて柔軟かつセキュアな運用が可能です。

たとえば，外部サービスに自身のGmailのアドレス帳へのアクセス権限を与えたい場合，そのサービスにGmailのメールアドレス＆パスワードを教えてしまうと，それらの情報が他のGoogleサービスでも悪用される危険性があります。極端な例ですが，最悪の場合は外部サービスにパスワードを変更され，Gmailアカウントを完全に乗っ取られることもあるでしょう。しかし，OAuthではパスワードを渡すこと無く認可情報を委譲することができ，さらに委譲する権限をGmailアドレス帳の読込権限に限定したり有効期限を設けることで，委譲のリスクを最小限に抑えることができます。

認可情報の委譲を行う似たような仕様には，GoogleやYahoo!，Flickr，Facebookなどが独自に提供しているものもありますが，OAuthがそれらと大きく違うのは，仕様がオープンなことです（もちろん皆さんは，オープンな仕様を好むでしょう？）。

最近ではGoogle，Yahoo!，TwitterなどのAPIでも独自認証やBasic認証と併用する形でOAuthのサポートが広がっています。またOpenSocialでのOAuthの利用やOpenIDとOAuthのハイブリッド仕様など，その他のオープンな仕様との連携も注目されています。

OAuthの登場人物

OAuthには，大きく分けて3つの登場人物がいます。1つ目はOAuth Service Provider（以下Service Provider）と呼ばれる，ユーザの認可情報を第三者に渡すサービス。2つ目はOAuth Consumer（以下Consumer）と呼ばれる，Service Providerから認可情報を受け取り，ユーザに代っていろいろな情報にアクセスしたり変更／追加を行ったりするサービス。3つめが，Userです。UserはService ProviderがConsumerに認可情報を渡すことを許可したり，すでに受け渡した認可情報を無効にするといったことができます。

この連載では，第1回はUserから見たOAuthを実感し，第2回と第3回はConsumerの実装を通してConsumer側から見たOAuthを理解し，第4回にはService Providerの実装を通してOAuthの全貌を理解します。