-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
