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

From: Doug Tangren <[email-masked]>
Date: Thu, 12 May 2011 01:08:39 -0400

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 11 May 2011 22:26:09 -0700

The name needs to be unique enough not to conflict with likely parameters already used by providers. I don’t have an opinion which name is better, just that it was oauth_token before and when we changed the scheme name to Bearer, changed it too.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug Tangren
Sent: Wednesday, May 11, 2011 10:09 PM
To: [email-masked]
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?

-Doug Tangren
http://lessis.me

---

From: Mike Jones <[email-masked]>
Date: Mon, 23 May 2011 18:38:15 +0000

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

-Doug Tangren
http://lessis.me

---

From: David Recordon <[email-masked]>
Date: Sat, 28 May 2011 09:30:07 -0700

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
<[email-masked]> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Doug Tangren <[email-masked]>
Date: Sat, 28 May 2011 13:14:33 -0400

-Doug Tangren
http://lessis.me

> token into a field named bearer_token.
I still agree it's confusing. It also depends on which resource server token
type handling you choose. If you were going to choose
mac token types, the access_token is actually named "id" [1] in the
authorization header though its oauth2 binding suggestions the auth server
returns it as a parameter named "access_token" [2]

[1]:
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-3.1
[2]:
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-5.1

> developers will have never heard of a bearer token.
I feel the same. My company actually needs a way to distinguish between
oauth1 [3] and oauth2 [4] because we are currently supporting both. We are
currently inspecting requests using "oauth_token" to identify oauth1
requests and "access_token" to identify oauth2 requests.

Until things get a little more finalized in the resource server specs, my
company just accepts an access_token param instead of adopting mac or bearer
drafts. Once they get finalized people will probably feel more comfortable
developing consistent oauth2 client libraries. I've seen both mac and bearer
drafts completely change parameter names. I'm waiting for those to become
stable before building something on top of them.

 It seems facebook has currently adopted the "access_token" parameter name
and foursquare has adopted the "oauth_token" parameter for oauth2. That
makes it difficult for people to build consistent client libraries when
providers choose different naming schemes for the same protocol.

[3]: http://www.meetup.com/meetup_api/auth/#oauth
[4]: http://www.meetup.com/meetup_api/auth/#oauth2

---

From: David Recordon <[email-masked]>
Date: Sat, 28 May 2011 10:20:24 -0700

Facebook accepts both access_token and oauth_token today but only
documents access_token. I imagine we'll continue doing the same with
bearer_token until it gets sorted out a bit more. Thus we'd document
access_token but note that oauth_token and bearer_token will also
work. :-\

On Sat, May 28, 2011 at 10:14 AM, Doug Tangren <[email-masked]> wrote:
> [1]: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-3.1
> [2]: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-5.1
>

---

From: "William J. Mills" <[email-masked]>
Date: Tue, 31 May 2011 12:03:16 -0700 (PDT)

Except int he "bearer" authentication scheme, in which it is not named.

________________________________
From: David Recordon <[email-masked]>
To: Mike Jones <[email-masked]>; Doug Tangren <[email-masked]>; "[email-masked]" <[email-masked]>
Cc: paul Tarjan <[email-masked]>
Sent: Saturday, May 28, 2011 9:30 AM
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type

--David

---

From: George Fletcher <[email-masked]>
Date: Tue, 31 May 2011 15:29:57 -0400

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

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          Home: [email-masked]
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch