Hi Subbu,
> -----Original Message-----
> From: Subbu Allamaraju [mailto:su...@subbu.org]
> Sent: Tuesday, January 18, 2011 10:43 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme
>
> Could you clarify what the "confusing mess" part is? The cited reference [1]
> is
> not useful.
It was not meant to be useful... :-)
> It is good to adhere to the challenge-response model of 2617 for wider
> interoperability and discoverability (yes, WWW-Authenticate with a well-
> known scheme name helps discovery and lack thereof reduces protocol
> visibility).
There are two separate issues here. First, whether the HTTP authentication
model with its challenge response architecture is suitable for OAuth
(authorization). Second, if the currently defined response header field
provides any level of interoperability. My answer is no to both. I'll explain.
OAuth is an authorization protocol not an authentication protocol. With the
exception of the client password credentials passed in the form-encoded body,
the protocol is completely authentication agnostic for both client
authentication and end-user login. Add to that the recent separation of the
token authentication schemes, and you get a clean and well defined
authorization model.
A client using a token has to answer two questions: how to obtain authorization
and how to use the provided authorization to access the protected resource. As
currently specified, the header answers neither. In addition, for this to be a
challenge response protocol, the client response must match the challenge which
is not possible if the response can use different schemes based on the token
type issued. That has proven very confusing to people on this list.
The only case a client is going to encounter the WWW-Authenticate header is
when making an unauthenticated request (the three error codes provided add
little to no value on top of the existing HTTP status codes). The only time
that will happen is when the client is unfamiliar with the server. In such a
case, the protocol as specified provides no further steps. The resource server
is saying 'I support OAuth2' but implicitly saying 'and good luck figuring out
what to do next'. For this to provide any actual interoperability at this
level, the header must provide the supported profiles, endpoints, extensions,
scope, etc. None of that is currently available.
This means the header is defined solely as a potential future extension point
for discovery, which brings me back to the first issue. The WWW-Authenticate
header is not the right place to provide authorization server discovery
information. I think our inability to fit 'realm' into our framework shows how
the HTTP authentication headers are not meant for this.
EHL
> Subbu
>
> On Jan 14, 2011, at 10:32 PM, Eran Hammer-Lahav wrote:
>
> > One of the main problems with OAuth in general has always been the
> unsanitary mix of authorization and authentication ("it's an authentication
> protocol... authorization protocol... authentication protocol" [1]). It has
> always
> been a confusing mess. The work on 2.0 has provided a valuable abstraction
> and separation of the two components, especially the recent document split.
> In addition, the recent work on the bearer token document and the MAC
> token type have raised issues about OAuth and its relationship with HTTP
> authentication.
> >
> > I would like to suggest we drop the 'OAuth2' WWW-Authenticate header
> completely from the specification for the following reasons:
> >
> > 1. Draft oauth-v2 is clearly not an authentication protocol. It
> > *utilizes*
> client authentication. It offers one fully defined method for client
> authentication (which is basically HTTP Basic+), provides a half-baked client
> assertion authentication hook, and leaves all end-user authentication out of
> scope.
> > 2. The WWW-Authenticate header has absolutely no value,
> interoperability-wise or otherwise. Discovery was rules to be beyond the
> scope of this specification. Having a protected resource declare it supports
> authentication using some unspecified credentials obtained using some
> unspecified client flow is confusing at best. In the future, an interoperable
> discovery mechanism will be needed to allow clients to interact with
> completely unknown protected resources, but this has been consistently
> ruled to be premature standardization at this point.
> > 3. OAuth is agnostic to token authentication, and we already have
> > three
> discrete token type proposals - all with active deployment plans in the
> coming months. Two of these methods have already defined a full HTTP
> authentication scheme (even if the bearer token specification has not yet
> been updated to change its scheme name).
> > 4. HTTP *authentication* is not an appropriate facility to negotiate
> *authorization*. OAuth authorization discovery can be added to HTTP
> authentication schemes as attributes, but makes no sense as a scheme of its
> own. The issues we are having with 'realm' is one of the examples showing
> that we are abusing the header.
> > 5. Again, as specified, it adds no value and I am not aware of any
> > existing
> OAuth 1.0a implementation making use of the response header for client
> interoperability (yes, many include it, but how many clients actually rely on
> it,
> and if they do, how?).
> >
> > For these reasons I would like to suggest we:
> >
> > 1. Drop the WWW-Authenticate header definition and OAuth2 scheme
> from the specification, leaving it up to each token type to define its own
> authentication flow. In the future, a comprehensive discovery specification
> should define a new HTTP response header for providing discovery
> information. I have suggested using Link: rel='authorization' as a simple yet
> powerful solution.
> > 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to
> make it clear what this document is really about.
> >
> > Comments? Counter argument?
> >
> > EHL
> >
> > [1] http://www.youtube.com/watch?v=0IBZocFkXGY
> >
> > _______________________________________________
> > 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
