Facebook accepts both access_token and oauth_token today but only documents access_token. I imagine we'll continue doing the same with bearer_token until it gets sorted out a bit more. Thus we'd document access_token but note that oauth_token and bearer_token will also work. :-\
On Sat, May 28, 2011 at 10:14 AM, Doug Tangren <d.tang...@gmail.com> wrote: > > -Doug Tangren > http://lessis.me > > > On Sat, May 28, 2011 at 12:30 PM, David Recordon <record...@gmail.com> > wrote: >> >> Did a full read through of draft 16 and the bear token spec with Paul >> yesterday afternoon in order to do a manual diff from draft 10. The >> point Doug raised was actually confusing. Throughout the core spec >> it's referred to as access_token but then becomes bearer_token upon >> use. >> >> Just thinking through this from a developer documentation perspective, >> it's going to become confusing. Developer documentation focuses on >> getting an access token and then using that access token to interact >> with an API. Thus the code you're writing as a client developer will >> use variables, cache keys, and database columns named `access_token`. >> But then when you're going to use it, you'll need to put this access >> token into a field named bearer_token. >> > > I still agree it's confusing. It also depends on which resource server token > type handling you choose. If you were going to choose > mac token types, the access_token is actually named "id" [1] in the > authorization header though its oauth2 binding suggestions the auth server > returns it as a parameter named "access_token" [2] > [1]: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-3.1 > [2]: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-5.1 > >> Feels quite a bit simpler to just name it access_token. Realize the >> core spec never did this since we didn't want to trample on protected >> resources which might already have a different type of access_token >> parameter. oauth_token was a good compromise since developers would >> already know that they were using OAuth and thus a new term wasn't >> being introduced. That's no longer true with bearer_token since 99% of >> developers will have never heard of a bearer token. >> > > I feel the same. My company actually needs a way to distinguish between > oauth1 [3] and oauth2 [4] because we are currently supporting both. We are > currently inspecting requests using "oauth_token" to identify oauth1 > requests and "access_token" to identify oauth2 requests. > Until things get a little more finalized in the resource server specs, my > company just accepts an access_token param instead of adopting mac or bearer > drafts. Once they get finalized people will probably feel more comfortable > developing consistent oauth2 client libraries. I've seen both mac and bearer > drafts completely change parameter names. I'm waiting for those to become > stable before building something on top of them. > It seems facebook has currently adopted the "access_token" parameter name > and foursquare has adopted the "oauth_token" parameter for oauth2. That > makes it difficult for people to build consistent client libraries when > providers choose different naming schemes for the same protocol. > > > [3]: http://www.meetup.com/meetup_api/auth/#oauth > [4]: http://www.meetup.com/meetup_api/auth/#oauth2 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
