OAuth was designed to combat an anti-pattern.
Typing your username and password into a third party site is bad idea. A really bad idea. I mean, you may think it’s a bad idea to give your bank details to a Nigerian prince but that’s just peanuts compared to giving away your password to an untrusted site!
So, that’s why we use OAuth. Rather than handing details to a random site, we authenticate against a trusted site which then redirects us back with an authentication token.
That’s all well and good on the web, but on mobile apps it becomes a little more difficult.
This is the popular mobile game Temple Run. After dying in the game (as I frequently do!) you can Tweet your score. But, first, you need to connect with Twitter.
However, clicking the button, presents this screen:
This is a pop-up within the game. What you see in the screenshot is the totality of what the user sees.
There are now two important questions:
- How can the user tell if this is the genuine Twitter site?
- Why is there no indication that the site is served over HTTPS?
This is a clear anti-pattern! We’re teaching people to give over their usernames and passwords to sites that appear to be genuine – yet offer no way to validate their legitimacy.
We’ve been trying to educate people to look at the URL bar – to check that they’ve visited the correct site and that there’s some form of SSL verification (commonly a padlock).
I’m not suggesting that Temple Run is doing anything other than pointing to the correct site. Just that they aren’t giving the user a chance to verify the authenticity.
How To Solve This Problem
I haven’t the foggiest! Thoughts?
We can’t rely on the user having the Twitter app installed and firing via intent (or similar).
Due to the huge variety of phones and Operating Systems, there’s no easy way (that I know of) to redirect from a website back to the app.
There needs to be a way to keep everything in-app to keep the user experience.
So, come on then oh great minds of the Internet, how do we fix this?