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. > 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. > 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). Subbu _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
