Brief pointer to the "history" of this change. This change was adopted in draft 4 of the bearer spec as there were concerns with the previous parameter name of 'oauth_token'. The suggestion was made to use 'bearer_token' so that it matches the scheme used in the Authorization header. The thinking being that reading the bearer token spec would seem weird if the Authorization header used one name and the GET/POST methods used a different name.

The 'bearer_token' name got a few +1 and no dissents.

Full thread starts here [1]. Mike accepting the 'bearer_token' recommendation is here [2].

Thanks,
George

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
[2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html

On 5/28/11 12:30 PM, David Recordon wrote:
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 Mon, May 23, 2011 at 11:38 AM, Mike Jones
<michael.jo...@microsoft.com>  wrote:
The working group explicitly decided that a different name should be used,
to make it clear that other token types other than bearer tokens could also
be used with OAuth 2.



                                                             -- Mike



From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Doug Tangren
Sent: Wednesday, May 11, 2011 10:09 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] consistency of token param name in bearer token type



This may have come up before so I'm sorry if I'm repeating. Why does bearer
token spec introduce a new name for oauth2 access tokens [1],
"bearer_token", and before that [2], "oauth_token"?



I apologize if this may sound shallow but, why introduce a new parameter
name verses sticking with what the general oauth2 spec already defines,
"access_token". It seems arbitrary for an auth server to hand a client an
apple then have the client hand it off to the resource server and call it an
orange.



Was this just for the sake of differentiating the parameter name enough so
that the bearer tokens may be used in other protocols without being confused
with oauth2 access_tokens?



[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2

[2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2



-Doug Tangren
http://lessis.me

_______________________________________________
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


--
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george.fletc...@teamaol.com
AOL Inc.                          Home: gffle...@aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to