こんばんは、ritouです。
今日、発表されたTwitterのScopeについては他の人がたくさんブログなど書いているので省略します。
気がつけば、OAuthのScopeについてはずっと前から考えさせられることが多かったのです。
Y!やGのScopeの要求の仕方が気になったのは2009年最初のあたりだったので、もう2年以上も前のことですね。
The Scope for OAuth ( ネットサービス ) - Web Life!!! - Yahoo!ブログ
少し振り返ってみましょう。
Scopeの要求方法
ClientがServerに必要なScopeを指定する方法として、大きく分けて２種類存在します。
- Client ID(Consumer Key)を取得するタイミングで必要なScopeを指定
- AuthZ Requestを送るタイミングで必要なScopeを指定
前者は、Yahoo!やヤフーや以前悪名高いtwitterなどが採用しています
後者は、Google、Facebook、mixiなどもこの方法を採用しています
わずかな経験から実装する側の立場も考えて、前者がとりあえず簡単そうだななんて考えたりもしたけれども、たくさんのAPIが提供される時代になればなるほど、その時に必要な最小限のScopeを動的に要求していく後者の方がこれからは主流になっていくのではないかと考えたりしています。
動的指定の場合のアクセス権限管理
動的に指定する形式をとったときに、気になるのが許可したアクセス権限の管理です。
例として、現状は以下の2種類が存在するようです。
- Client単位にユーザーが直近で許可したScopeを管理
- Client:Scopeの組み合わせ単位管理
例として、あるユーザーがあるClientAに対して最初にプロフィール、次にプロフィール＋メッセージREADの権限に同意するとしましょう。
前者でいうと、ClientA : プロフィール＋メッセージREADというアクセス権限を管理して、無効化できたりするのでしょう。
後者の場合は、ClientA : プロフィール、ClientA : プロフィール＋メッセージREADの2種類を管理することになります。こんなめんどくさいことを、あのGoogleがやっていた記憶があってブログも書いた気がしますが、、、見当たりません。
これも、うまく作りこむClientには機能単位で必要最低限のタイミングで必要最低限なScopeを要求していくが実現できて便利かもしれませんが、アクセス権限の無効化画面ではClient単位で一括無効化するなど、ユーザーがめんどくさーにならないように工夫しなければなりませんね。
細分化とグルーピング、そして標準化
GoogleやFacebookのScopeはたくさんあります。
FacebookのOAuth経由で同意画面にずらーと並んだアイコンを見たことがある人も多いでしょう。
Twitterのように大雑把過ぎるのも困りものですが、細かくしすぎるのもなかなかわかりづらいものです。
また、Clientの開発者としては、各Server単位でドキュメントを読んで作りこんでいく必要があります。
- 細かくしまくって、ユースケース単位のScopeのグルーピング
- 適切なScopeを標準化し、みんながそれを利用
PortableContacts、ActivityStreamsのように次々とデータのやりとりで標準仕様とされているものもあるので、Scopeもそのあたりうまく考えていけないものかなぁ。
VenderCentricなので難しいところですね。
ユーザーの取捨選択
最後に、ユーザーが自由に取捨選択できる機能はどうなのかという点です。
OpenIDでは、ヤフーがAXで渡す属性をユーザーが同意画面のチェックボックスで操作することが可能です。
今のOAuthの同意画面は０（拒否）か１（許可）の世界です。
Facebookの同意画面の話に戻りますが、○○をしたいだけのサービスのくせにやたらとたくさんのScopeを要求されるってことがあります。
要求されたScopeリストに対してユーザーがこのデータは渡していいと思うものだけ選択して同意する、それこそが本来あるべき姿ではないのでしょうか？
と、言うのは簡単ですが、悪い言い方をすると"返ってくればもうけもの"のAX属性とOAuthのScopeではClient側の実装への影響も大きく異なってきますので、難しそうですね。
おわり
Twitter様のおかげでようやくOAuthのScopeの話が開発者の間で浸透してきました。
この動きを続けてユーザーにも開発者、Serverとしても使いやすい/使われやすい姿を目指していきたいものです。
