Oauth 2.0 user deniable scope

Clientが要求したPermissionをユーザーが拒否できる設計

OAuthのClientやモバイルアプリがユーザーにPermissionを要求するときに、ユーザーがそのPermissionを部分的に拒否できない仕様になっているのがほとんどである。

現状の課題

このようなClient主導なPermission要求仕様は実装がシンプルにはなるものの、ユーザーにとってはAll or Nothingの選択を迫られるものである。

• OAuth Serverは指定されたscopeの値について同意を求めるだけで済む
• OAuth Clientは成功のレスポンスが返ってきた場合は指定したscopeに関連するPermissionをもらったものとして扱える

「ユーザーがPermissionを個別に拒否できる」ようなOAuth Serverの設計

ユーザーが要求されたPermissionを個別に拒否できる設計にするとどうなるかを検討する。
検討にあたり、今回は2つの実装を参考にする。

• facebookのExtended Permission
• Yahoo! JAPANのOpenID 2.0 AXの実装 (※OAuthではない) Yahoo! JAPANのOpenIDがAX＋popup始めました
• OpenID ConnectのOpenID Request Object OpenID Request Object

Facebookはメッセージのやりとりなどいくつかのscopeに関してはユーザーが拒否できる。
Y!JのOpenID 2.0のAX実装では要求された属性情報に対してユーザーが渡すのを拒否できる。
そもそもOpenID 2.0のAXではopenid.ax.requiredとかいうパラメータで必須項目を指定できたりする。
Connectの属性情報要求でもessentialの値を用いて任意項目を指定できる。

詳細は端折るが、だいたい３種類ぐらいの実装案に落ち着くのかなと思っている。

1. 指定したscopeパラメータに紐づくPermission全てに対してユーザーが拒否できる
2. OAuth Serverがあらかじめ決めておいたscopeパラメータに紐づくPermissionのみ拒否できる
3. OAuth ServerではなくOAuth Clientが"拒否されてもいい"scopeをextended_scopeのように指定する

1つのscope=1つの権限になっていなかったり組み合わせが必要な場合もあると思いscopeに紐づくPermissionと表現した。

ユーザーにとって1が理想であるだろう。
2はFacebookと同様である。「ServerがProfile情報などはほとんどのClientで必要だろう、でもメッセージとかは嫌がるかもね」というような考慮があってユーザーとClientにとって親切かもしれない。
3はユーザー主導とは言えない。

既存のPermission要求ロジックとの関係

1,2を実装するのであれば既存のAuthorization Endpointとは別にエンドポイントを用意する必要がありそう。Permissionが拒否されても正常に動作するように作りこまれたClientはそちらを使うイメージ。 3については既存のエンドポイントにextended_scopeのようなパラメータのサポートを追加することで実現できそう。

仕様との差異

1.2は特にパラメータなどを拡張しなくても良い。
3は新規scopeパラメータが必要なのでOAuth 2.0の仕様からは少し外れる。