You are correct. If a AS, supports the username and password profile, that means it can be used by any client. Clearly the user has made a trust decision about the client in this case, assuming there really is a user running the client.
One option for a provider to minimize their exposure is they may not issue Access Tokens that have as much power to Clients using the Username and Password profile. This is a good point to call out in the currently un-written security considerations. -- Dick On 2010-03-05, at 12:17 AM, Jason Hullinger 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 <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 <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" <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 <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 <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 <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 oauth-wrap...@googlegroups.com. >>>> > To unsubscribe from this group, send email to >>>> > oauth-wrap-wg+unsubscr...@googlegroups.com. >>>> > For more options, visit this group at >>>> > 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 oauth-wrap...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> oauth-wrap-wg+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> 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 oauth-wrap...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> oauth-wrap-wg+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> 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 oauth-wrap...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> oauth-wrap-wg+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> 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 oauth-wrap...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> oauth-wrap-wg+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> 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 oauth-wrap...@googlegroups.com. >> To unsubscribe from this group, send email to >> oauth-wrap-wg+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth WRAP WG" group. > To post to this group, send email to oauth-wrap...@googlegroups.com. > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
