Marius/Kris, Are we talking about Native apps where no browser (internal or external) is available (e.g. set-top-box)?
If a browser is available, I would not want to confuse the user with authentication at the service provider with local branding of the app. OAuth does a nice job of keeping these separate as we've already seen in the OAuth 1 implementations. Per what Marius is saying, the user experience [for a particular resource provider] should be the same regardless of user-agent or web server. If a browser is not available, I've seen out-of-band methods work very well too. E.g. code via SMS, code via email. The issue that client credentials on installed apps aren't very good is becoming well known (see the other threads on authorization code security). Even if well protected (which is debatable), the problem is there are many many clients with the same legit code. We need something that so that a server can determine it is accepting an access token request from the same client that originally requested an authorization. There is also a follow on problem that without a unique client app (per instance) identifier, you can't easily revoke access to that client without impacting every other client with the same identifier. Phil phil.h...@oracle.com On 2011-04-04, at 12:14 PM, Marius Scurtescu wrote: > On Mon, Apr 4, 2011 at 12:09 PM, Kris Selden <kris.sel...@gmail.com> wrote: >> I completely agree with you regarding not being able to authenticate a >> native client. >> >> The problem with web flow is the user experience is bad for a native app. >> Why does this matter? Because of competition – if competitors use a user >> friendly but less secure method and the end user does not know it is bad for >> them, then because of market forces you have to do the same. > > User experience should be identical for both User-Agent and Web Server > flows. With User-Agent typically you get only a short lived access > token, so for more cases this will not work at all for native apps. > > Marius > _______________________________________________ > 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