I am not sure I understand this exactly, but I don't see the need. Basically, the token endpoint requires client authentication (yeah, with exceptions). The spec provides one super-simple way to accomplish that using form-encoded parameters, but that's really focused on the hardcoded clients - those pointed at known services. While libraries will support the two parameters, it is unlikely that clients will use it to obtain a token from an unfamiliar server (since they are not registered).
IOW, the client password credential authentication described in the spec is a useful hack for the common needs most API developers today have, based on existing API keys used. I would hate see this expanded to more hack-ish client authentication schemes using parameters. In general, alternative client authentication methods (which have nothing to do directly with the two parameters), should be defined or adopted for client authentication using normal HTTP authentication headers. The way to think about this is to remove client authentication from the token endpoint and just assume the server doesn't care about client identity. You give it a grant and get back an access token. Now, since we do care about client identity, we add client authentication *on-top* of the endpoint. The two parameters are therefore a hack which adds authentication into the endpoint. New schemes should work outside the request. EHL > -----Original Message----- > From: Phil Hunt [mailto:[email protected]] > Sent: Monday, January 24, 2011 2:56 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > endpoint? > > Why not have the token server specify a form based authentication for > OAuth token requests? > > WWW-Authenticate: Form url="/tokenrequest.jsp" > > Thus, a server could respond: > 401 Unauthorized > WWW-Authenticate: Basic realm="example" > WWW-Authenticate: Digest realm="example" > WWW-Authenticate: Form url="/tokenrequest.jsp",realm="example" > > Normally, a form would have caused a redirect, but in this case we aren't > talking about browser based clients so the redirect doesn't make sense. This > gives the clients a choice and a way to discover parameters (if really > needed). > By parsing the form, it could discover what form parameters are required. I > suspect as Eran indicates below, this wouldn't happen to often as site server > documentation would already make this clear. > > Phil > [email protected] > > > > > On 2011-01-24, at 2:25 PM, Eran Hammer-Lahav wrote: > > > This is pretty straight-forward. There are no special parameters to > > indicated > which client authentication is being used. It's either there or not, using > whatever the server supports. > > > > Simply have the token endpoint return a 401 with these WWW- > Authenticate headers. As long as you make it clear how to make between > the client identifier and the credentials used, you are set. > > > > For example, a token response can return: > > > > 401 Unauthorized > > WWW-Authenticate: Basic realm="example" > > WWW-Authenticate: Digest realm="example" > > > > There is no discovery for support for the client_id and client_secret > parameters. The client can simply try it or hardcode it based on the server's > documentation. > > > > Does this help? > > > > EHL > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Monday, January 24, 2011 1:10 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > >> endpoint? > >> > >> Hi all, > >> > >> I'm currently thinking about the integration of existing HTTP > >> authentication schemes with OAuth 2.0 for the purpose of end-user > >> authentication on the tokens endpoint. Possible candidates are "Digest" > >> for challenge-response-based username/password authentication and > >> "Spnego" for Kerberos-based authentication. Direct support for both > >> could be beneficially in enterprise and other security sensitive > deployments. > >> > >> An direct integration with the tokens endpoint would allow to > >> leverage existing implementations and infrastructure for > >> OAuth/HTTP-based architectures. For example, HTTPClient has direct > >> support for Spnego- Authentication. > >> > >> Both HTTP authentication schemes use dedicated WWW-Authenticate > and > >> Authorization headers for passing credential and other data between > >> client and server. OAuth in contrast uses grant types to indicate the > >> authentication method, credentials are passed as URI query parameters > >> and it lacks any discovery of available authentication methods/ grant > types. > >> > >> How could one integrate existing schemes into that design? What is > >> our story? Do we need to define a special grant type "HTTP > authorization"? > >> Shall Authorization headers overrule URI parameters? > >> > >> Any ideas of the WG are higly appreciated. > >> > >> regards, > >> Torsten. > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
