mixi engineer blog

*** 引っ越しました。最新の情報はこちら → https://medium.com/mixi-developers *** ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

mixi PlatformがOAuth 2.0の最新仕様に対応しました

はじめまして、研究開発グループのritouです。

人々が7インチタブレットの話題で盛り上がっていた10月24日、mixi PlatformはOAuth 2.0の最新仕様のサポートを開始しました。
OAuth2.0 RFC6749へ対応しました << mixi Developer Center (ミクシィ デベロッパーセンター)
その内容について紹介します。

mixi Graph APIとOAuth 2.0の進化

Webアプリ、モバイルアプリなどがmixi Graph APIを用いてユーザーデータにアクセスする際、ユーザーから許可を得る必要があります。mixiアプリやmixiページアプリからもmixi Graph APIを利用できます。認証認可と呼ばれるこの機能の実装について、今まではOAuth 2.0 draft v.10をサポートしてきました。
OAuth 2.0の仕様策定の中で、2010年7月に更新されたdraft v.10は「様々な環境で動作するアプリケーションから利用でき、署名つきのリクエストの代わりにHTTPSのリクエストを使う」ための機能を備えた実用的なバージョンです。mixi以外にもいくつかのサービスがdraft段階から採用したことでOAuth 2.0が話題になりました。
その後、IETFにて様々なユースケースに対応できる"拡張性"を意識した策定が進み、2012年10月に2つのRFC仕様が誕生しました。

  • RFC 6749 - アプリケーションがユーザーからAPIアクセスのための許可を得る方法
  • RFC 6750 - 許可を得たアプリケーションが署名を用いずにAPIにアクセスする方法

mixi Platformはこの2つのRFC仕様に対応しました。

差分

draft v.10とRFCの差分については、以下のドキュメントで確認できます。
新旧認証認可仕様比較 << mixi Developer Center (ミクシィ デベロッパーセンター)

アクセストークンの発行、再発行時のレスポンスにはAccess Tokenの種類を表す"token_type"が追加されました。mixi Platformにおいて指定される"Bearer"という値は、「ここで渡したAccess Tokenは署名なしでリソースアクセスに利用できる」ことを示しています。
それ以外の旧仕様で返していたパラメータに変更はありません。

例:アクセストークンの発行時のレスポンス
{
 "refresh_token":"4af76ea612e5a6c28aedc21104237bb25eba2311",
 "expires_in":900,
 "access_token":"f23878290385fdd758d3ba7086448e7183aef289",
 "token_type":"Bearer",
 "scope":"r_profile"
}

「APIアクセス時のアクセストークン指定方法」と「エラー」に関しては既存のClientに影響がないように互換性を持たせています。下記の条件にあてはまるリクエストに対しては、今まで通りのエラーレスポンスが返されます。

  • Authorization Headerが"OAuth"から始まる文字列
  • URI Query Parameterに"oauth_token"が存在

curlコマンドでPeople APIをたたく例を用いて違いを説明します。
まずは旧仕様のリクエストを送ります。

curl -I -H "Authorization: OAuth (有効期限切れのAccess Token)" \
  https://api.mixi-platform.com/2/people/@me/@self

HTTP/1.1 401 Authorization Required
...
WWW-Authenticate: OAuth error='expired_token',realm='api.mixi-platform.com'
...

WWW-Authenticateレスポンスヘッダが"OAuth"から始まり、エラーの内容が"expired_token"となっています。

次に、RFC6750にて定義されているリクエストを送ります。

curl -I -H "Authorization: Bearer (有効期限切れのAccess Token)" \
  https://api.mixi-platform.com/2/people/@me/@self

HTTP/1.1 401 Authorization Required
...
WWW-Authenticate: Bearer realm="api.mixi-platform.com", error="invalid_token", error_description="The access token expired"
...

WWW-Authenticateレスポンスヘッダが"Bearer"から始まり、エラーの内容が"invalid_token"となっています。

mixi Platformでは今後もdraft v.10のサポートは続けていきますので、パートナーの皆様に今すぐに対応をお願いするものではありません。改修のタイミングや今後新たにmixi Graph APIを利用する際には、最新仕様に沿った実装にしていただければと思います。

OAuth 2.0の仕様がRFC化されたことにより、今後は対応するプラットフォームが増え、各言語のServer/Clientライブラリも出揃うでしょう。仕様自体がOAuth 1.0よりも簡単になったとはいえ、安全な実装のためにライブラリの活用は重要でしょう。今回紹介したServer側の対応も、OAuth::Lite2というライブラリで差分をうまく吸収できたため、mixi内部の改修箇所はそれほど多くありませんでした。
mixi Platformが対応したことにより、OAuth 2.0の実装ノウハウがサービスを超えて共有できるようになり、Client開発の負荷軽減につながることを期待しています。

ではまた!