Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token

[Eran Hammer-Lahav <eran at hueniverse.com>]

*** It would be helpful if other people chime in on this topic. This is a critical decision we need to make regarding new schemes. One proposal is to have different scheme for different type of access (direct vs. delegated). Another is to reusing existing scheme (with a new MAC-based one) for both usernames and tokens, and differentiating them on the server side using the credential structure (token or username) and on the client side using the realm parameter (and the header order). Of course, there are probably other proposals coming. ***

> -----Original Message-----
> From: oauth-bounces at ietf.org [mailto:oauth-bounces at ietf.org] On Behalf
> Of Manger, James H
> Sent: Saturday, October 03, 2009 8:13 PM
> To: oauth at ietf.org
> Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token
> 
> > My point is only that the existing deployment of Basic
> > prevents it from being used in the way you proposed because
> > it is more likely to break things and does not offer any real benefit
> > (other than a theoretical cleaner architecture),
> > and less work for the spec editor.
> 
> 
> One very real benefit is that established authentication schemes, such
> as BASIC, are already supported by
> frameworks/libraries/systems/infrastructure/plumbing. I think Eran
> stated that one aim of the current OAuth work was to get OAuth
> supported in those contexts, not just as app-layer libraries.

(not sure why you are talking past me...)

The existing support for Basic is not going to make a big difference because the goal is to get the new authentication scheme (the one that works without SSL) deployed. Are you suggesting that reusing Basic is the way to get transport-layer support? That doesn't get us much.

> Consider a networking library (eg java.net.URLConnection) that adds
> support for TOKEN XXX WWW-Auth schemes (in addition to existing support
> for BASIC etc). The library has no way of knowing if a caller is making
> a request in a "direct" or a "delegated" context so it has no way of
> knowing if it should react to BASIC or TOKEN XXX. All it can do is ask
> the caller (eg via a caller-supplied java.net.Authenticator), "Have you
> got a username/password for this address/port/protocol/realm/scheme"?
> 
> If both a BASIC and a TOKEN PLAIN WWW-Auth header are present in a 401
> response, java.net.URLConnection will ask java.net.Authenticator about
> both in turn (probably in the order they appear) until it gets some
> credentials. The process is the same if two BASIC headers are present -
> - it asks about both until it gets an answer. If BASIC and MAC (TOKEN
> HMAC) headers are present it might ask about the MAC header first as it
> is the stronger algorithm.  [P.S. I assume this is how Java works, but
> I haven't confirmed all the details yet]

The problem with this flow is that it doesn't account for a new, non-username based authentication method. The only way this can work with your proposal is by using the realm as the only differentiator between usernames and tokens. I think this is an abuse of the realm parameter and given all the other problems we have with defining realm, is just asking for problems.
 
> > Direct access by clients does work well with existing username-based
> schemes
> > because that's what it is - direct access.
> > We have two distinct cases: direct access and delegated access.
> > The issue is to have both direct access and delegated access coexist
> on the same resource.
> 
> I don't think this divide works.
> People have made lots of use of the OAuth 1.0 request signing mechanism
> for delegated access and for "2-legged" direct access.
> If TOKEN HMAC is not usable for "2-legged" direct access then it misses
> half the proven use cases.
> Is removing support for "2-legged" request signing intentional?

Removing support for "2-legged" was intentional in my proposal only in the sense that it is something we should figure out separately. Our charter allows us to define a new authentication method for HTTP that is useful beyond the delegation use case. However, the current way people are using OAuth 1.0 for direct access is mixed. Some use the client credentials as username/password, omitting the token. Others give clients special tokens to use with API calls that do not have a user context.

There are many ways to take whatever new auth scheme we come up with and enable it for the non-delegated use case. But given this is a secondary goal, I would like to first come up with the best authentication scheme we can for delegation and then review it for the 2-legged use cases. Either way, there is no requirement for us to define a single auth scheme. We can define two schemes with identical syntax but different names, one for delegation and another for usernames (just one of many ways to address this).

BTW, OAuth is being used in many unexpected ways all of which are of little interest to us. We are not trying to maintain every possible use case someone found for 1.0.

EHL