I think the problem comes up if you want to authenticate using some other means (e.g. client_assertion) using form based authentication. At that point separation between the token end-point and platform security is not clear. The client_id and client_secret approach also has the same issue of not separating client authentication from the token request.
One possible flow might be: Step 1: client: request token (no client credential supplied) Step 2: server responds with authentication required, returns HTTP 401 as below 401 Unauthorized WWW-Authenticate: Basic realm="tokenSvc" WWW-Authenticate: Digest realm="tokenSvc" WWW-Authenticate: Form url="/clientAuthenticate.jsp",realm="tokenSvc" Step 3: client elects form based authentication by responding to the form returned from clientAuthenticate.jsp. For example, the form might require client_assertion, or other form based authentication approaches. Step 4: server authenticates and returns a "client" token used token requests. Step 5: client goes to original token endpoint and by client authorization token (in Authorization header) and original request. Sure the spec says client_id and secret, but doesn't allow for the form to specify other required elements the site wants to impose. By actually asking for the form, the client can discover what is needed. Also, steps 1-4 might only have to be done relatively infrequently. Once a client is authenticated, it could make multiple OAuth token requests for multiple grant codes. Another variation (combined token and client auth) is a case where authentication field and token request are combined in one form. Not sure if WWW-Authenticate should indicate that variation. Phil phil.h...@oracle.com On 2011-01-24, at 3:11 PM, Eran Hammer-Lahav wrote: > 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:phil.h...@oracle.com] >> 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 >> phil.h...@oracle.com >> >> >> >> >> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
