This is why the username/password profile is intended for rich client apps, where invoking a browser is not feasible. Given that the user already downloaded and installed the rich app, popping open a browser is not going to protect the user from a malicious app for instance, a malicious app could have installed a keylogger before invoking the browser.
Under no circumstances should web applications use the username/password profile. Obviously, a browser is available in this scenario. However, for rich apps, requiring the app to pop open a browser does protect the user from malicious apps, and that¹s why it is OK for these apps to directly ask the user for their password. However, it¹s generally much better to invoke a browser for instance, CAPTCHA and other anti-password cracking defenses and be deployed without having to rewrite clients that are already in the field. Also, some users may need to authenticate with more than just a password for instance users might have hardware/sms tokens or might need to answer a secret question. Allen On 3/5/10 12:17 AM, "Jason Hullinger" <sshja...@gmail.com> wrote: > If it's impossible to validate who a client is for even one particular > protocol in the spec, doesn't this leave a provider's web service open to > anyone making an authentication/login request to that implemented profile in > the spec? Unless I'm missing something, this is a problem because a provider > would be opening themselves up to likely phishing attacks, and no way to stop > it except by shutting down the entire protocol that allowed it. Perhaps this > is just a documentation issue because implementing this portion of the > spec could potentially make a provider less secure with no real way of > stopping it after it's implemented. > > ~/Jason Hullinger > > On Thu, Mar 4, 2010 at 9:37 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >> As was discussed on the OAuth list, desktop apps can NOT be secured, so there >> is no way to ensure it really is the desktop app you think it is. For most >> phone platforms, this is also the case. For totally locked platforms where >> the app is part of the OS (xbox, PS3, some phones, settop boxes) -- then one >> can have high confidence the app is the app. So far I consider these the >> exception rather than the rule. >> >> -- Dick >> >> >> On 2010-03-04, at 8:37 PM, David Recordon wrote: >> >>> +ietf list >>> >>> >>> On Mar 4, 2010, at 8:16 PM, Jason Hullinger < <mailto:sshja...@gmail.com> >>> sshja...@gmail.com> wrote: >>> >>>> I think there are probably going to be more instances of providers needing >>>> this than otherwise. The current Username and Password profile is not a >>>> solution in a for every sense, and there clearly is a need for a secure >>>> protocol where you can validate that the client is who they say they are in >>>> a profile such as on a phone or desktop application. >>>> >>>> ~/Jason Hullinger >>>> >>>> On Thu, Mar 4, 2010 at 7:30 PM, Luke Shepard < >>>> <mailto:lshep...@facebook.com> <mailto:lshep...@facebook.com> >>>> lshep...@facebook.com> wrote: >>>>> Is Facebook the only one who needs this? >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Mar 4, 2010, at 6:41 PM, "Dick Hardt" < <mailto:dick.ha...@gmail.com> >>>>> <mailto:dick.ha...@gmail.com> dick.ha...@gmail.com> wrote: >>>>> >>>>>> The spec allows the AS to define additional parameters, so for these >>>>>> specialized use cases, Facebook could ask Microsoft and Sony to include >>>>>> an identifier in the request. >>>>>> >>>>>> Is that adequate? >>>>>> >>>>>> On Thu, Mar 4, 2010 at 6:28 PM, David Recordon < >>>>>> <mailto:record...@gmail.com> <mailto:record...@gmail.com> >>>>>> <mailto:record...@gmail.com> record...@gmail.com> wrote: >>>>>>> Devices such as an XBox or PS3 can keep secrets which is primarily >>>>>>> where we envision using the username/password profile. >>>>>>> >>>>>>> On Thu, Mar 4, 2010 at 5:52 PM, Dick Hardt < >>>>>>> <mailto:dick.ha...@gmail.com> <mailto:dick.ha...@gmail.com> >>>>>>> <mailto:dick.ha...@gmail.com> dick.ha...@gmail.com> wrote: >>>>>>>> > >>>>>>>> > On 2010-03-04, at 3:58 PM, Luke Shepard wrote: >>>>>>>> > >>>>>>>>> >> On Mar 4, 2010, at 3:42 PM, Marius Scurtescu wrote: >>>>>>>>> >> >>>>>>>>>> >>> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger < >>>>>>>>>> <mailto:sshja...@gmail.com> <mailto:sshja...@gmail.com> >>>>>>>>>> <mailto:sshja...@gmail.com> sshja...@gmail.com> wrote: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> wrap_client_id - Required. The client identifier >>>>>>>>>>> >>>> wrap_username - Required. The User¹s username >>>>>>>>>>> >>>> wrap_password - Required. The User¹s password >>>>>>>>>>> >>>> wrap_scope - Optional. Authorization scope values defined by >>>>>>>>>>> the server >>>>>>>>>>> >>>> Additional parameters - Any additional parameter defined by the >>>>>>>>>>> >>>> authorization server >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> From the above parameters there is no way of insuring that a >>>>>>>>>>> client is ever >>>>>>>>>>> >>>> who they say they are because a user could easily obtain the >>>>>>>>>>> wrap_client_id >>>>>>>>>>> >>>> and make requests using that. Does anyone have an >>>>>>>>>>> implementation of this or >>>>>>>>>>> >>>> any recommended additional parameters? >>>>>>>>>> >>> >>>>>>>>>> >>> I don't think you need to trust this client itself in any way, the >>>>>>>>>> >>> user trusted the client and provided his/her username and >>>>>>>>>> password, >>>>>>>>>> >>> that's all that counts. The should just verify these credentials and >>>>>>>>>> >>> then issue refresh and access tokens. >>>>>>>>> >> >>>>>>>>> >> It's pretty important to Facebook that we be able to validate who >>>>>>>>> the client is when they pass in user credentials. We have pretty >>>>>>>>> strict restrictions on the ability for apps to take user credentials >>>>>>>>> directly and we need to be able to enforce those restrictions. I would >>>>>>>>> like to see the ability to authenticate the app as well in this >>>>>>>>> profile. >>>>>>>> > >>>>>>>> > This profile was motivated by the use case of rich clients where >>>>>>>> redirection of a browser is challenging. ie. a twitter app on a phone. >>>>>>>> > >>>>>>>> > Per previous discussions in OAuth, it is not feasible with current >>>>>>>> platforms for an app running on a user machine to keep secrets from >>>>>>>> malicious users. A web app of course can keep a secret from the user, >>>>>>>> but use of this profile by a web app does not seem to make sense. >>>>>>>> > >>>>>>>> > -- Dick >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > -- >>>>>>>> > You received this message because you are subscribed to the Google >>>>>>>> Groups "OAuth WRAP WG" group. >>>>>>>> > To post to this group, send email to >>>>>>>> <mailto:oauth-wrap...@googlegroups.com> >>>>>>>> <mailto:oauth-wrap...@googlegroups.com> >>>>>>>> <mailto:oauth-wrap...@googlegroups.com> oauth-wrap...@googlegroups.com. >>>>>>>> > To unsubscribe from this group, send email to >>>>>>>> <mailto:oauth-wrap-wg%2bunsubscr...@googlegroups.com> >>>>>>>> <mailto:oauth-wrap-wg+unsubscr...@googlegroups.com> >>>>>>>> <mailto:oauth-wrap-wg+unsubscr...@googlegroups.com> >>>>>>>> oauth-wrap-wg+unsubscr...@googlegroups.com. >>>>>>>> > For more options, visit this group at >>>>>>>> <http://groups.google.com/group/oauth-wrap-wg?hl=en> >>>>>>>> <http://groups.google.com/group/oauth-wrap-wg?hl=en> >>>>>>>> <http://groups.google.com/group/oauth-wrap-wg?hl=en> >>>>>>>> http://groups.google.com/group/oauth-wrap-wg?hl=en. >>>>>>>> > >>>>>>>> > >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "OAuth WRAP WG" group. >>>>>>> To post to this group, send email to >>>>>>> <mailto:oauth-wrap...@googlegroups.com> >>>>>>> <mailto:oauth-wrap...@googlegroups.com> >>>>>>> <mailto:oauth-wrap...@googlegroups.com> oauth-wrap...@googlegroups.com. >>>>>>> To unsubscribe from this group, send email to >>>>>>> <mailto:oauth-wrap-wg%2bunsubscr...@googlegroups.com> >>>>>>> <mailto:oauth-wrap-wg+unsubscr...@googlegroups.com> >>>>>>> <mailto:oauth-wrap-wg+unsubscr...@googlegroups.com> >>>>>>> oauth-wrap-wg+unsubscr...@googlegroups.com. >>>>>>> For more options, visit this group at >>>>>>> <http://groups.google.com/group/oauth-wrap-wg?hl=en> >>>>>>> <http://groups.google.com/group/oauth-wrap-wg?hl=en> >>>>>>> <http://groups.google.com/group/oauth-wrap-wg?hl=en> >>>>>>> http://groups.google.com/group/oauth-wrap-wg?hl=en. >>>>>>> >>>>>>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
