The short answer is that Facebook's current implementation is based off of draft 5, and the spec has changed significantly since then. Facebook has said that they're going to track to the final version of the OAuth2 spec once that's available, though.
Having a refresh token allows you to separate the credentials that can get stuff done (the access token) from the credentials that you store for a long time (the refresh token). Also, the refresh token is an optional part of the spec and not all providers will issue them. Hope this helps, -- Justin On Wed, 2010-08-25 at 03:13 -0400, shanew wrote: > 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.
