My point is that for client_id/client_secret this is not needed because clients are only likely to use it when dealing with a known server with well-known characteristics. Those defining other schemes, including client_assertion will need to figure out their client profile and how to address its needs.
EHL > -----Original Message----- > From: Phil Hunt [mailto:phil.h...@oracle.com] > Sent: Monday, January 24, 2011 3:39 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > endpoint? > > 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
