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
