RESTful API の認証と認可
OpenSocial の RESTAPI には @me というパラメーターがある。これは、「認証済みクライアント自身」をパラメーターとして渡すときに用いるようだ。
例えば、はてダの場合、yssk22 のURIは http://d.hatena.ne.jp/yssk22/ であって、これはクライアントのFirefoxが認証済み(Cookieを発行済み)の状態だろうが、未認証だろうが、常に http://d.hatena.ne.jp/yssk22/ で一意である。
ところが、OpenSocial のスタイルのAPIだと、yssk22 として認証済みのクライアントであれば、http://d.hatena.ne.jp/@me でアクセスしてもよいことになる。つまり、URIが、「認証に関しては」コンテキストを持つのである。
で、この辺のコンテキストの解決はどうやるの？というのがこのエントリの話題。
引用は全て http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.5 より。
Containers MUST be an [OAuth Core 1.0] Service Provider (a web application that allows access via OAuth). Containers MAY also support other ways to establish a request context.
ということで、OpenSocial Container を名乗るためには、OAuth Core 1.0 の Service Provider を実装しなければならないらしい。
Thus, a request context usually includes the requesting application (the OAuth Consumer), and MAY include the requesting user, either implicitly via an oauth_token or explicitly via xoauth_requestor_id.
ということで、@me というコンテキスト依存するパラメータを渡される場合は、oauth_token か xoauth_requester_id を使って、リクエストをしているユーザーを特定するのが良さそうだ。とはいえ、
It may also include additional information via extensions or other channels (cookies, URI parameters, client SSL certificates, etc.) A container may also accept requests with no authentication or authorization (authnz) information at all for public data. A container may provide a public version (e.g., of a profile) if no authnz information is provided.
ということなので、cookie とか client 証明書 などによるリクエスターコンテキストの解決をすることもよいらしい。
Note that the data provided for a given RESTful URI MAY vary per requestor or app.
