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

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-bounces@ietf.org [mailto:oauth-bounces@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