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 <b...@dehora.net> 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<j...@jkemp.net> 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 >>>>>>> >>>>>>> <mscurte...@google.com> >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike >>>>>>>> Jones<michael.jo...@microsoft.com> >>>>>>>> >>>>>>>> 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 >>>>>> >>>>>> 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
