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

[David Recordon <[e-mail]>]

Bearer token doesn't exist within the core spec around getting an
access token. The term that is used is "access token".


On Tue, Jun 14, 2011 at 8:12 AM, Bill <[e-mail]> wrote:
> 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
>>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>