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

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

The idea of using the realm value as a differentiator between username-based auth and token-based auth is wrong. This is not what the realm is for and it is already a misused feature. The consensus in the OAuth community has always been against even having realm in the first place, and while I disagree with that, it does indicate that building on top of that is a bad idea.

I would also argue that it should be perfectly valid to use the exact same realm (resource set) with both username-based and token-based credentials. Your proposal breaks that and forces servers to make up new realms that are not based on their server file hierarchy which is the most common approach.

The reality is that Basic and Digest auth are well established and used for username/password authentication. They are widely deployed and to overload them with a new meaning will likely cause more harm than good. At the same time, you are not offering any value by reusing them, other than making the spec shorter. Yes Basic is very useful but who needs the stupid base64 encoding or even the ':' separator between the username and password?

Yes, we need to figure out the discovery of how to get a token from a 401 response. One thing at a time.

EHL

> -----Original Message-----
> From: oauth-bounces at ietf.org [mailto:oauth-bounces at ietf.org] On Behalf
> Of Manger, James H
> Sent: Thursday, October 01, 2009 7:26 PM
> To: oauth at ietf.org
> Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token
> 
> >>   401 Unauthenticated
> >>   WWW-Authentication: BASIC realm="User access"
> >>   WWW-Authentication: BASIC realm="Delegated app access"
> > How is a client supposed to know what to do with this?
> 
> This is not enough to trigger a web-delegation flow -- we need another
> WWW-Auth header for that. Once a client has an id and shared-secret
> (whether from a web delegation flow, a configuration file, prompting a
> user operating the client...) the above header tells it to retry the
> request with a "Authorization: BASIC Zm9vOmJhcg==" header.
> 
> If the client was given a realm value when it got the id and shared-
> secret, then the two headers above indicate if those credentials can be
> used for this protected resource.
> If the client has its own id/secret and another id/secret as a delegate
> for another user, then the multiple realms can tell it which set the
> server is asking for.
> 
> 
> 
> > Digest has failed adoption
> 
> Fine, so we should be wary about reinventing it with "Token HMAC"
> unless that offers something significantly different. The ability to
> put the signature in the URI or body is different (but you want to drop
> that); simplicity may be different enough. Getting the credentials from
> a delegation flow is not a difference as it should be orthogonal.
> 
> 
> > Basic provides practically zero value
> 
> I don't understand how "Token Plain" can offer any more value than
> BASIC.
> (Personally I think BASIC is massively useful over HTTPS)
> 
> 
> 
> The "Token Plain" and "Token HMAC" WWW-Auth schemes look like a
> deliberate attempt to keep authentication and web-delegation tightly
> coupled. This must be unnecessary. I though the whole idea of splitting
> OAuth into authentication and web-delegation specs was that these are
> separate concerns. The authentication part is useful even if you didn't
> get the credentials via delegation. The delegation part is useful
> whatever authentication mechanism is subsequently used.
> 
> It seems like bad design to keep the authentication spec bound to web-
> delegation (though there will need to be some links in the other
> direction).
> 
> 
> 
> James Manger
> James.H.Manger at team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
> 
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth