Subject: [OAUTH-WG] Clarification: Authorization scheme :: Token vs OAuth

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 21:32:54 -0700

I recall some earlier discussion on calling the scheme Token vs OAuth and see that it is now Token per the example:

 Authorization: Token token="vF9dft4qmT"

Would explain or point out the logic of using Token rather than OAuth?

A related question: is the scheme case sensitive?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 18 Apr 2010 22:05:02 -0700

Scheme is always case-insensitive per 2617.

My reasons for using Token:

1. The scheme isn't specific to OAuth (which defines a model for obtaining tokens). It is a generic way to use tokens for authentication. Similar to how services use OAuth today for "2-legged" authentication (using the signature method without an access token at all), I expect services to use the Token scheme.

2. Doesn't conflict with OAuth 1.0, and doesn't require adding oauth_version=2.0 to every request. The fact that 1.0 used a parameter name prefix in the *header* was bad enough.

That discussion did not reach any consensus so I used the last proposed text. If people have a problem with that I'll add it to the open issues list.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Sunday, April 18, 2010 9:33 PM
To: OAuth WG
Subject: [OAUTH-WG] Clarification: Authorization scheme :: Token vs OAuth

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 10:06:20 -0700

Isn't "Token" as a scheme to generic/ambiguous?

If a protected resource accepts several types of Authorization
headers, how can it be sure this is an OAuth 2.0 token and not some
other kind?

If adding a version parameter is too verbose, how about "OAuth2" as scheme?

Marius

On Sun, Apr 18, 2010 at 10:05 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> 1. The scheme isn’t specific to OAuth (which defines a model for obtaining
> tokens). It is a generic way to use tokens for authentication. Similar to
> how services use OAuth today for “2-legged” authentication (using the
> signature method without an access token at all), I expect services to use
> the Token scheme.
>
>
>
> 2. Doesn’t conflict with OAuth 1.0, and doesn’t require adding
> oauth_version=2.0 to every request. The fact that 1.0 used a parameter name
> prefix in the *header* was bad enough.
>
>
>
> That discussion did not reach any consensus so I used the last proposed
> text. If people have a problem with that I’ll add it to the open issues
> list.
>
>
>
> EHL
>
>
>
>
>
>
>
> I recall some earlier discussion on calling the scheme Token vs OAuth and
> see that it is now Token per the example:
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 11:06:07 -0700

Initially I don't think it is a problem because only OAuth 2 servers will use it. Later it becomes a question of discovery and what you do once you get such a challenge from a server you are unfamiliar with.

I proposed Token because it is in line with other HTTP authentication schemes: Basic and Digest.

The name really doesn't matter that much, but I rather not use OAuth (to avoid the need to add oauth_version=2.0 to every header), and I rather not use a version number in the scheme name. If you don't like Token, feel free to suggest something else. I think it is very accurate to what is being done.

Also keep in mind that there are going to be other flows issuing tokens, and we already have both delegation and autonomous flows using the same scheme. So calling it OAuth doesn't really tell much more than Token. If I use a new flow to get a token, it doesn't really matter what happens as long as I end up with a token (with or without a secret).

Does this make sense?

EHL

> -----Original Message-----
> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Monday, April 19, 2010 10:06 AM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG
> Subject: Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs
> OAuth
> 
> If a protected resource accepts several types of Authorization headers, how
> can it be sure this is an OAuth 2.0 token and not some other kind?
> 
> > 1. The scheme isn't specific to OAuth (which defines a model for
> > obtaining tokens). It is a generic way to use tokens for
> > authentication. Similar to how services use OAuth today for "2-legged"
> > authentication (using the signature method without an access token at
> > all), I expect services to use the Token scheme.
> >
> >
> >
> > 2. Doesn't conflict with OAuth 1.0, and doesn't require adding
> > oauth_version=2.0 to every request. The fact that 1.0 used a parameter
> > name prefix in the *header* was bad enough.
> >
> >
> >
> > That discussion did not reach any consensus so I used the last
> > proposed text. If people have a problem with that I'll add it to the
> > open issues list.
> >
> >
> >
> > EHL
> >
> >
> >
> >
> >
> >
> >
> > I recall some earlier discussion on calling the scheme Token vs OAuth
> > and see that it is now Token per the example:
> >
> >
> >

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 14:06:32 -0700

> Initially I don't think it is a problem because only OAuth 2 servers will use it. Later it becomes a question of discovery and what you do once you get such a challenge from a server you are unfami…

I think that many protected resource that will support OAuth 2 will
also support other protocols, at least OAuth 1.0.

> The name really doesn't matter that much, but I rather not use OAuth (to avoid the need to add oauth_version=2.0 to every header), and I rather not use a version number in the scheme name. If you d…

Being so generic at some point it may require a parameter to tell what
type of token is this. At that point I think that OAuth with a version
or OAuth2 is better.

> Also keep in mind that there are going to be other flows issuing tokens, and we already have both delegation and autonomous flows using the same scheme. So calling it OAuth doesn't really tell much…

True, but I don't think we are trying to solve token based
authentication in general.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 14:31:45 -0700

> Sent: Monday, April 19, 2010 2:07 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > Initially I don't think it is a problem because only OAuth 2 servers will use it.
> Later it becomes a question of discovery and what you do once you get such
> a challenge from a server you are unfamiliar with.
> 
> I think that many protected resource that will support OAuth 2 will also
> support other protocols, at least OAuth 1.0.

Ok. Don't see how this is relevant. Each will use its own WWW-Authenticate header.

> > The name really doesn't matter that much, but I rather not use OAuth (to
> avoid the need to add oauth_version=2.0 to every header), and I rather not
> use a version number in the scheme name. If you don't like Token, feel free
> to suggest something else. I think it is very accurate to what is being done.
> 
> Being so generic at some point it may require a parameter to tell what type
> of token is this. At that point I think that OAuth with a version or OAuth2 is
> better.

Same is true if we call it OAuth and someone will try to use it for something else. The exact thing happened with 1.0 with the so-called 2-legged use case. It had nothing to do with the original use case of the spec, but people found it very useful. At some point you have to use some form of discovery.

> > Also keep in mind that there are going to be other flows issuing tokens, and
> we already have both delegation and autonomous flows using the same
> scheme. So calling it OAuth doesn't really tell much more than Token. If I use
> a new flow to get a token, it doesn't really matter what happens as long as I
> end up with a token (with or without a secret).
> 
> True, but I don't think we are trying to solve token based authentication in
> general.

Actually, we are chartered to do just that [1]:

"The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio)."

We can define an OAuth scheme and then another Token scheme. I just don't see the point.

EHL

[1] http://datatracker.ietf.org/wg/oauth/charter/