Perhaps I'm missing something here, but once a client has requested an access grant, the auth server is free to authenticate the end-user in whatever way it chooses, and it would seem sensible to signal authn requirements with standard HTTP headers.
Why, then, would you want to integrate existing HTTP schemes at the token endpoint instead of at the authorization endpoint? -- Bob Gregory On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Zitat von Eran Hammer-Lahav <e...@hueniverse.com>: > > > There is no clean way to do with without defining new HTTP > > authentication schemes. The token endpoints takes: > > > > 1. Client authentication > > 2. Authorization grant > > > > There is no user authentication. Even the resource owner password > > credentials is not user authentication but only validation of "some > > grant values". > > What's the difference from a conceptual point of view? In my opinion, > the resource owners password is used for both, authenticating the > resource owner and authorizing the token issuance. > > > > > What you can do is define an authentication scheme which will > > authenticate the client and provide the grant in one header, or > > the spec makes the grant type a required parameter, so a lonely > authorization header won't be suffiencent. > > > define a new grant type for such credentials. But you can't use > > That brings us back to the mix between POST parameters and authz > headers for credential transmission. Something you critized for good > reasons. > > > something like Basic or Digest to provide the resource owner's > > credentials. That's against the endpoint design. > > It's good to know that restriction, but I'm not happy :-( So based on > that information I would say, the only proper way to integrate > standard HTTP schemes would be to invent another endpoint for that > purpose. > > Comments? > > regards, > Torsten. > > > > > EHL > > > > > >> -----Original Message----- > >> From: tors...@lodderstedt.net [mailto:tors...@lodderstedt.net] > >> Sent: Monday, January 24, 2011 10:35 PM > >> To: Eran Hammer-Lahav; OAuth WG > >> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > >> tokensendpoint? > >> > >> Hi Eran, > >> > >> thanks for your response. My inquiry was about end-user authentication > and > >> not about client authentication. All http schemes I'm aware of > authenticate > >> users and I want to find a way to leverage them with OAuth to determine > the > >> token's identity. > >> > >> Regards, > >> Torsten. > >> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland > >> > >> -----Original Message----- > >> From: Eran Hammer-Lahav <e...@hueniverse.com> > >> Date: Mon, 24 Jan 2011 15:25:38 > >> To: Torsten Lodderstedt<tors...@lodderstedt.net>; OAuth > >> WG<oauth@ietf.org> > >> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > >> endpoint? > >> > >> 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
