Our love-hate relationship with OAuth
blog.icoloma.comI was surprised account duplication wasn't mentioned as a disadvantage. If a user taps the wrong button on their tablet, then they can end up with one or more duplicate accounts if the e-mails are different.
I currently have an e-mail confirmation screen that makes it clear a new account is about to be created. I seem to remember Stack Overflow getting me to click a button too. It adds no real burden to new (non-Twitter) users.
I'm still wondering about the best way to handle this in Rails though. Passing the OAuth hash data through a second request to confirm the e-mail doesn't feel quite right to me, even if I make an OAuth service object to clean up the code and some policies to standardise the hash.
If this is your case you may want to consider Mozilla Persona, which will default to OAuth for some providers such as GMail.
We do have bizarre situations like people logging in using Twitter or Yahoo accounts bound to GMail, but they are rarely an issue. It's more frequent the case where a user is trying to open their account page using the wrong GMail account.
Anyway, our plan is to detect multiple accounts with the same e-mail address and offer the user to merge them, but we are not sure about how to do this since e-mail addresses are not immutable.
I've been looking at OAuth a bit lately.
I'm amazed there is no open-source, drop-in HTTP proxy to authorise access to REST APIs. The closest I've found is PingFederate, which is kind of expensive, and DoorMan[1], which seems incomplete and unmaintained.
Am I the only person who'd find this useful? What are other people doing - building it into their APIs?
Most people are integrating libraries into the server side, I guess. Security HTTP proxies are something that I have only seen in banks.
Some are scripting it into the web server (nginx in this case): http://seatgeek.com/blog/dev/oauth-support-for-nginx-with-lu...
Interesting. I quite like that approach.