Yahoo! JAPANがOAuthのService Providerになりました！

こんにちは、IDプラットフォーム技術の近藤です。

2007年12月4日、OAuth Core 1.0という仕様が策定されてからGoogle、米Yahoo、TwitterなどのサービスプロバイダがOAuthに対応を行い、外部アプリケーションに対してユーザーリソースへのアクセス認可を開始しました。そして2009年7月9日、Yahoo! JAPANもOAuthのサービスプロバイダとしてリソースアクセスの提供を開始しました。

2009年4月下旬にOAuth Core 1.0の仕様にセキュリティ問題があることが発表されました。
Yahoo! JAPANのOAuthはその問題を解決したOAuth Core 1.0 Revision Aという仕様に従っています。この仕様に加え、Yahoo! JAPANはOAuth Session Extensionという拡張仕様を導入しています。

ここでは、OAuthをある程度知っていることを前提にYahoo! JAPANのOAuth(以下、Yahoo! OAuth)とOAuth Core 1.0 Revision Aで定められている仕様(以下、OAuth Core)との差異について説明していきます。

Yahoo! OAuthとOAuth Coreの違い

Yahoo! OAuthはOAuth Coreに仕様に加え以下の2点について拡張されています。

• Access Token取得時のレスポンスにxoauth_yahoo_guidパラメータとしてユーザー識別子を含む
• OAuth Session Extensionを採用

ユーザー識別子「GUID」とは？

OAuth Coreでは、ユーザがConsumerに対してアクセスを許可する際にService Providerからユーザー識別子を渡しませんので、Consumer上で認証状態のユーザーAccess Tokenを紐づけることになります。その場合、ユーザがConsumerからService Providerへ遷移し、Sevice Provider上で異なるユーザに切り替えてからConsumerにデータアクセスを許可した場合、Consumerはユーザの変化に気づくことはできません。

Yahoo! OAuthでは、OAuthのフローの「3.Access Tokenの取得」のレスポンスに記載されている通り、Yahoo! JAPANで認証状態のユーザーを識別するxoauth_yahoo_guidという値をレスポンスパラメータに含むことで、Consumer側でユーザの変化に気付くことができるようになります。OAuth Coreはシングルサインオンのしくみではないですが、Consumer上のユーザとYahoo! Japan上のユーザー識別子を紐付けることで、よりユーザ管理がしやすくなるのではないのでしょうか。

OAuth Session Extensionとは？

OAuth CoreではConsumerはユーザのクレデンシャルとなるAccess Tokenを用いて、Service Provider上からユーザの情報を取得してきます。Consumer上でAccess Tokenを保存して長く使いまわせるような状態にしておくことで、Consumerやユーザにとって便利になる一方で、情報漏えいによってAccess Tokenが流出し悪用されるリスクが高くなります。反対にAccess Tokenの有効期間を短くしたり使い捨てにすることでセキュリティ向上が図れますが、Service ProviderへConsumerがユーザデータアクセスを要求するたびにユーザに同意をとる必要があるので利便性が極端に落ちてしまいます。

Yahoo! OAuthでは、Access Tokenの有効期間を短くしてセキュリティ向上を図りつつ利便性を損なわないように、OAuthの拡張仕様であるOAuth Session Extensionを利用しています。

OAuth Session ExtensionではAuthorization Sessionというユーザの同意が有効な期間を別途定義し、この期間内であればConsumerがAuthorization Session Handleと呼ばれるパラメータを使用してAccess Tokenを再発行し、有効期限を更新することができます。これにより実質的にAccess Tokenの有効期限を長く保持し続けることが可能となります。また、ユーザ自身が同意を撤回することでAuthorization Sessionを無効にすることも可能です。

次にOAuth Session Extensionの実際のフローについて見ていきましょう。

ユーザが同意完了した後のOAuthのフローの「3.Access Tokenの取得」のリクエストまではOAuth Coreと同様の手順ですが、拡張仕様ではレスポンスのパラメータに新たに３つのパラメータが追加されます。

• oauth_session_handle（Access Tokenを再発行するのに使用する値）
• oauth_authorization_expires_in（ユーザ同意の有効期間＝２週間）
• oauth_expires_in （Access Tokenの有効期限＝１時間）

Consumer側でoauth_session_handleを保持しておき、必要に応じてAccess Tokenを更新する時に使用します。

• Access Tokenの有効期限が切れている場合

  Access Token	無効
  Session Handle	有効

  下記のようなエラーレスポンスが返ります

  	HTTP/1.1 401 Unauthorized
  	WWW-Authenticate: OAuth oauth_problem=access_token_expired
  	Content-type: application/x-www-form-urlencoded
  
          oauth_problem=access_token_expired
  

ここでAccess Tokenを更新するために、OAuthのフローの「4.Access Tokenの更新」に記載されているように期限切れのAccess Tokenをoauth_tokenにセットし、oauth_session_handleをパラメータにセットしてリクエストを送信して、新しいAccess Tokenを受け取ることができます。

• Access Token及びSession Handleの有効期限が切れている場合

  Access Token	無効
  Session Handle	無効

  下記のようなエラーレスポンスが返ります。

  	HTTP/1.1 401 Unauthorized
  	WWW-Authenticate: OAuth oauth_problem=permission_denied
  	Content-type: application/x-www-form-urlencoded
  
          oauth_problem=permission_denied
  

このレスポンスを受けた場合は、Consumerは再度、OAuthのフローの「1. Request Tokenの取得」からやり直しになります。

「補足」
OAuth Session Extensionでは、エラーレポートの拡張仕様であるOAuth Problem Reporting Extensionを採用しており、エラーレスポンスのWWW-Authenticate ヘッダ及びBODYにエラーの原因を含めております。

さいごに

以上、簡単にではありましたが少しとっつき難いYahoo! OAuthの独自の部分について説明させていただきました。
OAuth Session Extensionに完全対応しているOAuthライブラリはまだ少ないので、開発者の方向けにYahoo! OAuth対応のSDKを準備する予定です。

最後まで読んでくれてありがとうございました！