You wouldn't. The profile should include the client secret as well in the initial request. You could always issue a client a different secret for use with this profile as well.
--David On Mon, Mar 8, 2010 at 8:22 PM, Jason Hullinger <sshja...@gmail.com> wrote: > If one were to obtain the client id of a partner, under the vanilla > username/password profile, how would a provider prevent non-partners from > connecting to a provider who has implemented this profile? > > ~/Jason > > On Mon, Mar 8, 2010 at 8:01 PM, Allen Tom <a...@yahoo-inc.com> wrote: >> >> Hi Ethan - >> >> In Yahoo's case, we only allow the username/password profile for a very >> small number of applications written by Yahoo or by partners under >> contract, >> and only when opening a web browser is not feasible or desirable. We >> strongly discourage apps from using this profile, and it's unlikely that >> it'll ever be a public interface. >> >> We have a very strong preference that rich client apps invoke a browser >> window for the user to authorize the app. >> >> Other Service Providers have similar policies for their equivalent >> username/password profile. >> >> Allen >> >> >> >> >> On 3/8/10 6:51 PM, "Ethan Jewett" <esjew...@gmail.com> wrote: >> >> > On Sun, Mar 7, 2010 at 10:25 PM, Allen Tom <a...@yahoo-inc.com> wrote: >> >> 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. >> > >> > I disagree. There are a large and growing number of platforms on which >> > I can install a rich client application and be confident that it will >> > not be able to recover my username and password when I type them into >> > my web browser. To name a few that I use every day: >> > >> > 1. My iPod Touch (non-jail-broken, admittedly) >> > 2. Adobe AIR on my Windows XP system >> > 3. Mac OS X (users and applications do not run as administrators by >> > default) >> > >> > On a related note - What stops a provider from implementing the >> > username/password pattern on top of normal OAuth or WRAP (thereby >> > losing my business ;-)? The token can be pretty much any string of >> > text, so the client could embed the username and password into the >> > token. >> > >> > Ethan >> >> _______________________________________________ >> 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
