OK, thanks for clarifying. Back to your original questions. We've been handling this mostly in a single shared token endpoint. In a few cases we've gone with separate end-points because it made things easier. We've kept parameters such as scope consistent, since they are properties of the output token rather than the input authentication.
Precedent of authentication methods hasn't been an issue - the client only sends one. We haven't done any work on discovery, because the client wouldn't be sending the authentication credentials if it didn't know what it was doing already. We've also done some work on authentication plug-ins that find the credentials on the machine and use them, without telling the calling application exactly where they came from. We've talked about SASL/GSSAPI/PAM/SSPI style integration, but so far that hasn't seemed like a high-value proposition. On Wed, Jan 26, 2011 at 12:45 AM, <tors...@lodderstedt.net> wrote: > Hi Brian, > > you identified the use cases correctly. No interactive user-consent would be > required. > > Regards, > Torsten. > Gesendet mit BlackBerry® Webmail von Telekom Deutschland > > -----Original Message----- > From: Brian Eaton <bea...@google.com> > Date: Tue, 25 Jan 2011 09:53:20 > To: Torsten Lodderstedt<tors...@lodderstedt.net> > Cc: Eran Hammer-Lahav<e...@hueniverse.com>; OAuth WG<oauth@ietf.org> > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokensendpoint? > > Hey Torsten - > > I'm trying to parse through these messages to figure out the flows > you're interested in. > > I think you're aiming for rules like this one, right? > > kerberos authentication -> access token > > or > > digest authentication -> access token > > And furthermore your intended use cases are applications installed on > an end-users machine, where the end-users machine participates in some > kind of authentication service. For example, maybe the machine is > joined to some kerberos realm, or maybe the user has a smart card. > > Have I identified the use cases properly? Or are you dealing with > three-legged OAuth situations, where you actually want user consent on > a web page? > > Cheers, > Brian > > On Tue, Jan 25, 2011 at 12: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
