今回から始まった「ゼロから学ぶ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の全貌を理解します。
OAuthを体験してみる
smart.fmでGoogleのOAuthを使う
さて、それでは早速UserとしてOAuthを利用してみましょう。smart.fmでは、すでにsmart.fmにいる友達を探す際にGmailとYahoo! Mailのアドレス帳にアクセスするため、OAuthを利用しています。そこで今回はsmart.fmの友達検索を通じて、OAuthを体験することにしましょう。smart.fmのアカウントはお持ちですか?お持ちでない方はユーザ登録を。
- smart.fmのGmail友達紹介ページにアクセス
- 「Googleへ」と表示されているリンクをクリック
今あなたはGoogleのサイトにいて、Googleがsmart.fmにアドレス帳へのアクセス権を渡してよいかどうか、確認を求めているでしょう。「Grant access」をクリックしてアクセス権の委譲を許可すると、smart.fmがバックグラウンドであなたのアドレス帳にアクセスし、既にsmart.fmを利用している友達や、招待可能な友達などをリストアップして提示します。「Deny access」をクリックすると、1)の画面に戻ります。
ここで与えた認可情報は、smart.fm側で「メールアカウント認証を削除」というリンクをクリックするか、Googleの「認証済みのウェブサイト」からsmart.fm(記事公開時点ではまだwww.iknow.co.jpと表示されます)を取り除けば無効になり、もう一度1)からやりなおすことができます。アクセス権委譲の許可/拒否をそれぞれ体験してみてください。
何が行われていたのか?
上記のフローの裏では、以下のようなやり取りが行われています。
(User : あなた、Consumer : smart.fm、Service Provider : Google)
- 0.ConsumerはService ProviderからあらかじめOAuth利用許可を得る
- このステップは、具体的にはService ProviderにConsumer登録を行い、Consumer KeyとConsumer Secretという値を取得することで行います。
- 1.UserがConsumerに、Service Providerから認可が必要な情報へのアクセス権を取得するように指示する。
- 前述のGoogle OAuthの例では、認可が必要な情報はGmailのアドレス帳、アクセス権取得の指示はユーザがsmart.fmの「Googleへ」というリンクをクリックすることに相当します。
- 2.ConsumerはバックグラウンドでService Providerにアクセスし、未認可のRequest Tokenを取得する
- 第2、3回目のConsumerの実装で詳しく扱います。
- 3.ConsumerはUserをService Providerにリダイレクトさせる。この際Consumerは未認可のRequest TokenをURL Parameterに付加する
- 第2、3回目のConsumerの実装で詳しく扱います。
- 4.UserはService Provider上でConsumerへのアクセス権委譲を許可する。この際Service Providerは未認可のRequest Tokenを認可済とする
- Google上で「Grant access」をクリックすることに相当します。
- 5.Service ProviderはUserをConsumerにリダイレクトさせる。この際Service Providerは認可済のRequest TokenをURLに含める
- 最終回のService Providerの実装で詳しく扱います。
- 6.ConsumerはバックグラウンドでService Providerと通信を行い、認可済のRequest Tokenを実際のアクセス権を示すAccess Tokenと交換する
- 第2、3回目のConsumerの実装および最終回のService Providerの実装で詳しく扱います。
- 7.Consumerは6)で得られたTokenを利用して、特定の情報にアクセスする
- 第2、3回目のConsumerの実装で詳しく扱います。
0.は前もって行われているので、今回あなたが経験したのは1.と4.です。Access Token取得後は、ユーザが明示的にそのAccess Tokenを無効にするか、Access Tokenにあらかじめ設定された有効期限をすぎない限り、Consumerは何度でも情報にアクセスすることができます。
このフローについてもっと詳しく知りたい方は、OAuth Core 1.0のSpec第6章をご覧ください。
まとめ
さて、第1回はOAuthの概念を説明しました。第1回では以下の3点をしっかり押さえていただければ、次の記事もご理解いただけると思います。
- OAuthを用いてsmart.fmにGmailのアドレス帳へのアクセス権限を与えた
- OAuth Service Provider、OAuth Consumer、Userという登場人物
- Request TokenとAccess TokenというTokenベースの認可情報のやりとりと、そのおおまかなフロー