>> 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.
Why would the client developer/admin not look at the scheme? >>> 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? Nope. There is value in providing dev/debug-level discovery info. Saying nothing is worse. >>> 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? By not having this header or header with some impl specific scheme? I'm not sure how to answer this question since I can't guess all the operating conditions of libraries, tools and intermediaries. If I were to write an OAuth-capable proxy, this header would tell it how what code to trigger in the case of auth failures (such as refreshing an access token). Plenty of examples exist for naming things via headers in all MIME-based protocols. I'm not seeing the value in making the OAuth over HTTP more opaque. In any case, 401 responses MUST accompany a WWW-Authenticate header. Subbu _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
