> -----Original Message----- > From: Subbu Allamaraju [mailto:su...@subbu.org] > Sent: Tuesday, January 18, 2011 11:37 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme > > > On Jan 18, 2011, at 11:13 PM, Eran Hammer-Lahav wrote: > > > 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. > > I agree about the separation, but a better fix is to name the protocols that > the client can use for each step as part of this header. In any case, 401 > responses are required (a MUST in 2616) to have a WWW-Authenticate > header with a scheme. Dropping the header is not a choice that the OAuth > draft or can/should make. Leaving the scheme name choice to each > implementation would be confusing to the community.
It isn't that confusing. The 401 response will include the WWW-Authenticate header of the scheme used with the token issued for that resource. Since clients never even look at the header today, they will not be confused by anything. Server developers might be, but it should be addressed by writing quality token type specifications with clear examples. > > 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. > > Actually, providing an HTML representation for 401 responses with "here is > how to can get started to supply an Authorization header to access this > resource" is a good step towards discoverability. I hope you are kidding... providing discovery in human-readable format helps the client how? > > 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. > > Including identifiers (like media types, encoding names, or even auth > schems) as part of the protocol gives some indirection to their specifications > elsewhere (though not perfect, such as an IANA registry). Can you give actual examples of how such responses help an OAuth *library* accomplish any level of interoperability? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
