Re: [OAUTH-WG] Consistency in access token parameter

[Eran Hammer-Lahav <[e-mail]>]

I still don't know where you stand on the actual proposal. Is the spec currently confusing? If it is, please suggest alternatives.

EHL

From: Joseph Smarr [mailto:[e-mail]]
Sent: Tuesday, April 20, 2010 9:42 AM
To: Eran Hammer-Lahav
Cc: Luke Shepard; [e-mail]
Subject: Re: [OAUTH-WG] Consistency in access token parameter

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-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf
> Of Luke Shepard
> Sent: Tuesday, April 20, 2010 12:46 AM
> To: [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth