Why Shouldn't I Programmatically Submit Username/Password to Facebook/Twitter/Amazon/etc?

I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...

I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.

But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.

My question is:

• What are the reasons why I shouldn't do something like that?

I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!

Edit:

I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything l开发者_运维百科egally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?

If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.

As a user, I don't trust your site with my password. Period.

The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.

The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.

As already said above:

• The site (or the site owner) accessing your {google|yahoo|etc} account cannot be trusted not to change your password and kick you out of your account.

But I feel there are other good reasons:

• Many people use the same password on more than one site ore account (some could have the same password on gmail and paypal) and the site owner could abuse that

• The site owner doesn't want to be held liable for other site owners abusing your account

• The site owner could not be able to store your username and password in secure fashion. The site needs to be able to access them automatically. So on the server hosting there is stored everything needed to access those credentials.

And the hosting usually happens in a shared or virtual server with the hosting company administrators (and sometimes - if the hosting company isn't too conscious - fellow users) able to access them.

Security and Confidentiality. Period.

Even some websites like Facebook discourage using this approach in their TOS i believe. If so, it will be illegal to do so.