Re: [OAUTH-WG] consistency of token param name in bearer token type

[Bill <[e-mail]>]

On 10/06/11 17:45, David Recordon wrote:
> I think it's vital to have the GET and POST parameters make sense to
> every developer. I worry less about the authorization header since a
> developer implementing it will honestly be a stronger engineer.

I agree with David regardless of engineering strength, this is going to 
be confusing to developers. Also tho', devs are exposed to the access 
token response, not just the GET/POST bits. So ideally syntax would line 
up with how the token is obtained 
http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-5.1 and not 
just across requests using the token.

A possible clarifying change is to use something like "bearer_token" end 
to end.

[[[
{
        "access_token":"vF9dft4qmT",
        "token_type":"bearer_token", /* ? */
...
}


GET /resource HTTP/1.1
Host: server.example.com
Authorization: bearer_token vF9dft4qmT


GET /resource?bearer_token=vF9dft4qmT&...
Host: server.example.com


POST /resource
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

&bearer_token=vF9dft4qmT&...


HTTP/1.1 401 Unauthorized
WWW-Authenticate: bearer_token realm="example"
]]]


Bill


> Here's what I said earlier in the thread about my motivation:
>> 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.
>>
>> 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.
>>
>> Googling for "bearer token" turns up Eran's blog post titled "OAuth
>> Bearer Tokens are a Terrible Idea" and there isn't a single result on
>> the first page which explains what they are. Binging for "bearer
>> token" is equally scary.
>
> --David
>
>
> On Fri, Jun 10, 2011 at 9:34 AM, John Kemp<[e-mail]>  wrote:
>> George,
>>
>> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>>
>>> I definitely don't want to change the Authorization header naming scheme. I believe it should stay 'Bearer' because that's what the token is. We could make it...
>>>
>>> Authorization: Bearer access_token=vF9dft4qmT
>>>
>>> If that helps with consistency.
>>
>> Well, it might seem more consistent, but I'm not sure it's worthwhile to make the change just for that reason.
>>
>> Is it possible that the Bearer HTTP mechanism would ever take multiple parameters? In which case, having the ability to name the parameters of the Bearer mechanism might become more interesting.
>>
>> - John
>>
>>> I don't think we should be associating the term 'access_token' with the bearer security mechanism.
>>>
>>> Thanks,
>>> George
>>>
>>> On 6/10/11 8:35 AM, John Kemp wrote:
>>>> What does this mean for the HTTP Authorization header naming scheme for bearer tokens?
>>>>
>>>> As I understand this decision, we are discussing whether to standardize on the name "access_token" when a bearer token is sent as either a URL query parameter, or in a form POSTed body?
>>>>
>>>> Currently the HTTP Authorization header looks like this (from
>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05
>>>> ):
>>>>
>>>> GET /resource HTTP/1.1
>>>> Host: server.example.com
>>>> Authorization: Bearer vF9dft4qmT
>>>>
>>>> Is the proposal then that we have:
>>>>
>>>> 1. GET /resource?access_token=vF9dft4qmT
>>>> 2. POST /resource
>>>>
>>>> access_token=vF9dft4qmT&...
>>>>
>>>> 3.
>>>>
>>>> GET /resource HTTP/1.1
>>>> Host: server.example.com
>>>> Authorization: access_token vF9dft4qmT
>>>>
>>>> Can someone actually give the details of the proposal, or agree/disagree with the examples above?
>>>>
>>>> - John
>>>>
>>>> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:
>>>>
>>>>
>>>>> Yes, that's fine with me.
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>> On 6/10/11 4:20 AM, David Recordon wrote:
>>>>>
>>>>>> George, Doug and Eran are you alright with the Bearer token spec using
>>>>>> the parameter name "access_token" as well?
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu
>>>>>>
>>>>>> <[e-mail]>
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones<[e-mail]>
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> If you can drive a consensus decision for the name "access_token", I'd be glad to change the name in the spec.  I agree that the current names are confusing for developers.
>>>>>>>>
>>>>>>>>
>>>>>>> At Google we are getting the same feedback, that it is confusing for
>>>>>>> developers. It would definitely help if we could change the name to
>>>>>>> "access_token".
>>>>>>>
>>>>>>> Marius
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>