> -----Original Message----- > From: tors...@lodderstedt-online.de [mailto:torsten@lodderstedt- > online.de] > Sent: Sunday, July 24, 2011 12:36 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: redirect uri validation (was: Issue 15, new client registration) > > Hi Eran, > > let's move the discussion regarding redirect uri validation into another > threat. > > >Personally, given the clear direction the web is taking where > >applications are moving off hosted servers to mobile devices and > >in-browser software, I believe >that focusing OAuth 2.0 ability to > >identify a client based on a secret is counterproductive. > > funny you mention this. I was advocating in favor of native apps support in > OAuth 2 since I joined this group :-) And I'm not saying secrets should be > used to authenticate those apps, I never suggested that. > > >This is why my last rewrite put much more weight on the redirection > >URI and clarifying registration requirements. > > I think redirect uri validation is especially ineffective for this client > category.
It’s a big category. Hosted JS clients with https:// registered redirection URI provide pretty strong identification. > The authz server can check the redirect uri of such a client. But it can only > detect those malicious clients which are using another URI than the pre- > registrered uri (most probably web-based clients). Clients using the correct > URI are not neccessarily the legitimate clients. Why? > Because native apps will most likely use URLs with custom URI schemes > which are used to re-activate the app on the device through the local > browser. So there is not a single "endpoint" such a URI is pointing to, but > this > URI is resovled relative to every device. So a malicious app on one device can > perfectly use the redirect URI a legitmate client uses on another device and > it > will still receive the authz result. I agree. One of my OSCON OAuth 2.0 slide shows this flow with the comment "Registered custom scheme URI (custom://) provides weak client identification". However, native apps are much harder to use for a social engineering attack (compared to web apps) because the user has to install something proactively. This means showing the user the logo of the expected client should raise a red flag when it doesn't match the application being executed. > >OAuth 1.0 was highly criticized for failing to address client identity > >in public clients. I believe OAuth 2.0 offers a much better story, > >within the boundaries >of what’s possible today. > > Agreed. I think we must honestly discuss the value of client > authentication/identification itself. I personally think it is over-emphazised > right now. The strength of OAuth 2.0 is that it allows solutions where neither > client nor resource server have access or do store end-user credentials. > Client authentication is nice but not the main feature. Do you have any specific suggestions not already mentioned on the list? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
