

OAuth & One-Page Apps: Avoiding the Redirect - chucknibbleston
http://nicholasjacob.com/Javascript/2012/05/27/oauth--websockets-avoiding-the-redirect/

======
darklajid
I kinda sound like a grumpy old man, constantly complaining about the same
stuff. But..

For the love of everything that's holy, stop adding these totally useless
social media bars that are floating on top of your potentially interesting
content. This entry is unreadable on the go, I'll probably forget to come back
later today and the only thing I'll recall is that there was another "of
those" useless submissions.

~~~
jarofgreen
Yes. Nicholas: this is what your site looks like in Android 4.0
<http://twitpic.com/9q8c7c> \- in other words, unreadable.

------
ew
We, Backup Box, are a one page app and we do OAuth without redirect all the
time. In fact we have one script that handles all the OAuth processes and any
new ones we need to create just pop in and there's no customization to be
done.

I open a new window (tab) with the OAuth process and since I opened the tab I
can redirect to some quick closing script and my main code is waiting for the
auth process to finish. Once it does the user is through. Easy peasy.

<https://mybackupbox.com>

~~~
mikeknoop
Presumably you have the auth flow in the new tab finish on a simple page
containing a script. What does that script do to notify the original window
that the auth flow is finished?

~~~
vnorby
If you open the OAuth flow in a pop-up, with window.open (actually, for most
browsers to open a pop-up, the user has to actually click on a link, so your
href should be javascript:window.open("<https://oauth_start>) -
target="_blank" might work as well but I can't remember), after the user has
completed the authentication and ended back up on your site, you can trigger a
function on the parent window and close the pop-up, like
window.parent.facebookAuthenticationComplete(); window.close(); I think this
is a lot easier and more reliable than pushing anything through a node/pub-sub
solution.

~~~
chucknibbleston
I agree; the whole node socket/handshake is a ton of overhead if you're not
interested in using the socket to make calls over the API you just
authenticated.

------
pshc
That page is spazzing out at me in Mobile Safari. Some kind of responsive
style script conflicting with Safari's auto-formatter?

------
clarle
Is there a best practice of doing authentication for single-page apps when you
don't want to use an external OAuth provider, since a lot of people don't have
Twitter/Facebook accounts?

Would you end up writing your own OAuth provider in that case?

~~~
chucknibbleston
Unless you're providing an API/external access for your users, you can just
use authentication internal to your app. It's pretty easy to roll your own
(here's a tutorial for doing it in RoR:
<http://www.aidanf.net/rails_user_authentication_tutorial>), but I would
recommend using a popular plugin/middleware if you can find it for your
language/framework so you don't have to worry as much about security.

For node/Express, passport.js is a good option (but doesn't help you out with
the database at all) -- <http://passportjs.org/guide/username-password.html>

Django has basic user authentication built-in, Ruby on Rails has Devise -
<https://github.com/plataformatec/devise> and AuthLogic -
<https://github.com/binarylogic/authlogic>.

I'd recommend reading the Ruby on Rails security guide about user management
to get an idea of some of the challenges in building an authentication system:
<http://guides.rubyonrails.org/security.html#user-management>

If you want to write an OAuth provider here's a great PHP tutorial:
[http://djpate.com/2011/01/13/how-to-write-a-complete-
oauth-p...](http://djpate.com/2011/01/13/how-to-write-a-complete-oauth-
provider-in-php5/)

------
drivebyacct2
that chart makes an extremely simple flow extraordinarily hard to understand.

