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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
