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 <[email protected]> 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 < <[email protected]> > [email protected]> 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 < > <[email protected]><[email protected]> > [email protected]> wrote: > >> Is Facebook the only one who needs this? >> >> Sent from my iPhone >> >> On Mar 4, 2010, at 6:41 PM, "Dick Hardt" < >> <[email protected]><[email protected]> >> [email protected]> 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 < >> <[email protected]><[email protected]><[email protected]> >> [email protected]> 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 < >>> <[email protected]><[email protected]><[email protected]> >>> [email protected]> 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 >>> >>> <<[email protected]><[email protected]><[email protected]> >>> [email protected]> 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 >>> > <[email protected]><[email protected]><[email protected]> >>> [email protected]. >>> > To unsubscribe from this group, send email to >>> <oauth-wrap-wg%[email protected]><[email protected]><[email protected]> >>> [email protected]. >>> > 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 >>> <[email protected]><[email protected]><[email protected]> >>> [email protected]. >>> To unsubscribe from this group, send email to >>> <oauth-wrap-wg%[email protected]><[email protected]><[email protected]> >>> [email protected]. >>> 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 >> <[email protected]><[email protected]> >> [email protected]. >> To unsubscribe from this group, send email to >> <[email protected]><[email protected]> >> [email protected]. >> 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. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth WRAP WG" group. >> To post to this group, send email to >> <[email protected]><[email protected]> >> [email protected]. >> To unsubscribe from this group, send email to >> <oauth-wrap-wg%[email protected]><[email protected]> >> [email protected]. >> 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. >> > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth WRAP WG" group. > To post to this group, send email to <[email protected]> > [email protected]. > To unsubscribe from this group, send email to > <[email protected]> > [email protected]. > 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. > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth WRAP WG" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
