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

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 19 April 2010 18:06 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7447F3A68C4 for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 11:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level:
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0cV0XLsvT0K for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 11:06:29 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 807873A6836 for <oauth@ietf.org>; Mon, 19 Apr 2010 11:06:19 -0700 (PDT)
Received: (qmail 29003 invoked from network); 19 Apr 2010 18:06:11 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Apr 2010 18:06:11 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 19 Apr 2010 11:06:03 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Marius Scurtescu <mscurtescu@google.com>
Date: Mon, 19 Apr 2010 11:06:07 -0700
Thread-Topic: [OAUTH-WG] Clarification: Authorization scheme :: Token vs OAuth
Thread-Index: Acrf4rF3l5cIBRUwTjaBWmfrisSo/QAB15PQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438E5C7F16D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <9CEC5DA2-6D5F-4CDB-80CD-D24F80E19969@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A3796@P3PW5EX1MB01.EX1.SECURESERVER.NET> <s2t74caaad21004191006rb29139f6lc9082b6b94afbec9@mail.gmail.com>
In-Reply-To: <s2t74caaad21004191006rb29139f6lc9082b6b94afbec9@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2010 18:06:30 -0000

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:mscurtescu@google.com]
> 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
> 
> 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
> <eran@hueniverse.com> wrote:
> > 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 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
> >
> >
> >
> > 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?
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >