In my experience, a frequent source of bugs/frustration for developers implementing OAuth 1.0 was the fact that we have multiple "tokens" that are easy to mix up and use in the wrong place. For instance, when I helped Dave Winer debug his implementation (see http://josephsmarr.com/2009/02/17/implementing-oauth-is-still-too-hard-but-it-doesnt-have-to-be/), the problem ended up being that he was passing his request-token instead of his access-token when making API requests (they're both returned as oauth_token, after all). (So I'd strongly urge us to pick as disparate names for the various "tokens" in OAuth 2.0 as possible, and to not use similar variable names when returning them, to minimize these chances of mix-up. It's probably also helpful if they look visually distinct, so it would be more obvious "oh, you're using the wrong kind of token here", but that may be too hard to enforce in practice.)
Thanks, js On Tue, Apr 20, 2010 at 8:04 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote: > There is an explanation (I'm not defending it, just explaining). > > In the flow endpoint I chose 'access_token' over token because of the > refresh token. It seems better to talk about two different kinds of tokens > than to have one generic 'token' and one with special meaning > 'refresh_token'. > > The protected resource endpoint is the only place I agree requires a prefix > because it always intrudes on another namespace or platform and the > likelihood of a conflict is high. I used 'oauth_token' instead of > 'oauth_access_token' for brevity thinking that it should be trivial to > figure out what to put there (the only other option is a refresh token which > isn't likely to be confused here). > > The header uses 'token' because it is a generic authentication scheme which > doesn't mandate you use the OAuth flows to get a token. This is the only > place I feel strongly about not changing it. > > Feel free to propose new names. > > EHL > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Luke Shepard > > Sent: Tuesday, April 20, 2010 12:46 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Consistency in access token parameter > > > > There are potentially three names for access tokens in this spec: > > > > - token > > - access_token > > - oauth_token > > > > You hit the /oauth/access_token endpoint, and get back access_token=blah. > > Then you take that string and pass it to the protected resource as > > oauth_token=blah. > > > > Developers that have prototyped things over here have found this to be > > confusing. It's simpler to just take the same named param everywhere. > > > > I vote that one of two things happen: > > > > 1/ Return oauth_token from the access token endpoint. > > 2/ Accept access_token on the protected resource endpoint. > > 3/ Return "token" (and still "refresh_token") from the access_token > > endpoint, and accept "token" on the protected resource. > > > > I know there will be infinite debate about the right way to do this, but > just > > wanted some thoughts for now. I will probably choose #2 as that seems > most > > explicit, even though it's a few more characters. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
