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
