Why we need client / direct login methods in open protocols
There were some good discussions at IIW this week about direct login methods for clients in general and also about if OpenID should support such methods.
Keeping aside the phishing, untrusted clients issues and in general good principles we follow in the Identity world, here are the reasons why i think we need to provide 'direct' login methods (with redirects and UI):
- not all clients have access to a browser/browser control objects
- user exp is considered as broken when a client app opens an external browser window
- even though some clients could embed browser control objects with themselves, not all can do that (flash apps, mobile app, ...)
- smart developers (ofcourse hackers) find otherways anyway for password cracking and phishing attacks (IMAP is a perfect example with almost every provider supporting it for easier access to mail. The Mail module in netvibes is a perfect example that provides access to AOL/Yahoo/GMail/... using IMAP/SMTP Protocols - though they are not really doing any malicious activities it still collects user credentials on a different domain)
- good developers are always ready to implement better security in their apps if they are asked to by providing better tools and documentation
- by providing a direct api, IDPs can still have control on several things like better rate limiting, captcha and enforce additional security measures like access revocation, user permission management, etc.
I am really looking forward to see more discussions around this - we in AOL have been struggling a lot with this since last one year or so mainly after the Web 2.0 boom. It was interesting to see our friends at Yahoo! and Plaxo struggling with the same - which makes it a even better case to start thinking about solving it in the Open & community driven protocols.
- alavillipraveen's blog
- Login or register to post comments
- Subscribe
