Except int he "bearer" authentication scheme, in which it is not named.
________________________________
From: David Recordon <record...@gmail.com>
To: Mike Jones <michael.jo...@microsoft.com>; Doug Tangren
<d.tang...@gmail.com>; "oauth@ietf.org" <oauth@ietf.org>
Cc: paul Tarjan <paul.tar...@fb.com>
Sent: Saturday, May 28, 2011 9:30 AM
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
