Our implementation is actually currently draft 0 but we're finalizing a patch that will bring it up to draft 10. :)
On Wed, Aug 25, 2010 at 6:42 AM, Justin Richer <[email protected]> wrote: > 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] <oauth%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > > -- 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.
