Facebookの認証ダイアログの仕様変更をまとめてみた

皆さんFacebook使ってますか?私はどちらかというとTwitterを使ってます。
下記のポストで説明されているのですが、Facebookが認証ダイアログの仕様を変えるようです。この変更が中々興味深い感じだったのでまとめてみます。
https://developers.facebook.com/blog/post/633/

変更点

今回の主な変更点は4つです。

1. ユーザーによるアプリのactivityの公開範囲設定

Facebookではウォールのポストごとに公開範囲を設定できますが、同じようにアプリがウォールにactivityを投稿する際の公開範囲を認証ダイアログで設定できるようになります。開発者がdeveloper appのDefault Activity Privacyでデフォルトの公開範囲を設定できるようにもなります。

2. アプリの説明エリアの追加

そのままなのですが、認証ダイアログにアプリの説明を行うためのエリアが追加されます。ユーザーにとっても開発者にとっても、アプリの説明が行えることはありがたいことですね。

3. Optionalなpermissionの表示

Extended permissionsを認証ダイアログの2つ目の画面で表示するようになります。この画面では、ユーザーに対して要求されているOptionalなpermissionを提示し、ユーザーはこれらのpermissionを拒否することもできるようになります。
また、developer appのExplanation for Permissionsの項目にpermissionを要求している理由を記入することができます。
あと、offline_access permissionがdeprecadeになります。あの、有効期限が設定されないaccess tokenのやつです。その代わりにaccess tokenを交換してexpireをresetすることが可能になるようです。

4. シームレスな認可手順の採用

この機能を有効にするとFacebook上でアプリのインストールを行う際にinlineでダイアログを表示することができるようです。

ユーザーによるpermissionの拒否について

3つめの変更が面白いですね。Facebookが定義しているpermissionはUser & Friend Permissionsと呼ばれるpermissionとExtended Permissionsと呼ばれるpermissionに大きく分類される(page用のpermissionもあったりはします)のですが、今回の認証ダイアログ変更でユーザーが拒否を行うことができるようになるpermissionはExtended Permissionsのみです。

実際に試すと以下のような感じになります。

まず、authZ endpointにリクエストします。今回はscopeにはuser_about_me(User & Friend Permissions)とread_friendlists(Extended Permissions)を指定してみます。

https://www.facebook.com/dialog/oauth?client_id=&redirect_uri=&scope=user_about_me,read_friendlists&response_type=code

認証ダイアログはこんな感じになっています
f:id:bang_yy:20120131003718p:image
インストールすると2つめの画面が表示されるので、
f:id:bang_yy:20120131003719p:image
右上の×ボタンでpermissionの拒否ができます。
f:id:bang_yy:20120131003720p:image
このあとGraph APIを使ってユーザーが許可しているpermissionを確認すると、

https://graph.facebook.com//permissions?access_token=

{
   "data": [
      {
         "installed": 1,
         "user_about_me": 1
      }
   ]
}

のように、ちゃんと拒否できていることがわかります。

開発者はaccess tokenを取得した時点ではユーザーが許可したpermissionを把握することができないので、Graph APIを使うなどしてユーザーに許可されたpermissionを確認する必要があります。ユーザーに許可されていないpermissionが必要な機能を選択された時点で"この機能を試すにはpermission: aを許可する必要があります"などと表示してauthZ endpointへのリンクを提示するようにするのがいいのでしょうか。

まとめ

ユーザーのコントロールできる範囲が広がり、良い方向で仕様変更が行われたように感じました。ついでと言っちゃ何ですが、この調子でaccess tokenとかをJSONで返すようにしてくれないですかね...