I've recently been experimenting with the Facebook graph API (http:// developers.facebook.com/docs/authentication/ in particular "Authenticating Users in a Web Application") which is advertised as OAuth 2 compliant. I'm relatively new to OAuth, and not familiar with the evolution of the specification so my first reading was OAuth draft- ietf-oauth-v2-10.
As part of these two activities I made the following list of general observations and was hoping that someone on this list could help address them (I suspect many are historical divergence of the OAuth spec): 1. OAuth 2-10 says the request to the authorize URL MUST contain the response_type parameter, however the Facebook authorize URL doesn't require it and seems to always imply it is "code". 2. Similarly in the request for an access token (section 4) the specification requires the grant_type parameter, but the Facebook access_token URL endpoint does not. It would appear this is defaulted to "authorization_code", at least for Web application authentication. 3. Section 4 also indicates the request for an access token should use HTTP POST with the response being a JSON object containing the response parameters, however the Facebook access is advertised via GET and even though both GET and POST work, the response string is encoded like a query string not JSON. This seems a little odd given that the actual graph API resources themselves are returned using JSON. 4. I noticed in section 3.1 Authorization Response in the description of the code parameter returned by the authorization server that "The authorization server MUST invalidate the authorization code after a single usage". In my experimentation with the Facebook API the authorization code can be replayed and the same authorization token is returned each time. I'm not convinced this adds any risk, but still appears to be non-compliant. 5. When requesting a resource I can access the graph API using an OAuth access token as a query string parameter as demonstrated in the Facebook documentation, but cannot seem to access it if I pass the same access token using the OAuth header as described in section 5.1.1. The OAuth specification indicates the Authorization header technique of presenting the access token MUST be supported. 6. Finally (and nothing to do with Facebook), I don't see much purpose in having a refresh token. Really, what's the point? The access token could just be valid for the lifetime of the grant. Thanks, Shane. -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
