What are the different options for social authentication on Appengine - how do they compare?

Question

[This question is intended as a means to both capture my findings and sanity check them - I'll put up my answer toute suite and see what other answers and comments appear.]

I spent a little time trying to get my head around the different social authentication options for (python) Appengine. I was particularly confused by how the authentication mechanisms provided by Google can interact with other social authentication mechanisms. The picture is complicated by the fact that Google has nice integration with third party OpenID providers but some of the biggest social networks are not OpenID providers (eg facebook, twitter). [Note that facebook can use OpenID as a relaying party, but not as a provider].

The question is then the following: what are the different options for social authentication in Appengine and what are the pros and cons of each?

Answer 1

In my research on this question I found that there are essentially three options:

1. Use Google's authentication mechanisms (including their federated login via OpenID)

   • Pros:
     • You can easily check who is logged in via the Users service provided with Appengine
     • Google handles the security so you can be quite sure it's well tested
   • Cons:
     • This can only integrate with third party OpenID providers; it cannot integrate with facebook/twitter at this time

2. Use the social authentication mechanisms provided by a known framework such as tipfy, or django

   • Pros:
     • These can integrate with all of the major social authentication services
     • They are quite widely used so they are likely to be quite robust and pretty well tested
   • Cons:
     • While they are probably well tested, they may not be maintained
     • They do come as part of a larger framework which you may have to get comfortable with before deploying your app

3. Roll your own social authentication

   • Pros:
     • You can do mix up whatever flavours of OpenID and OAuth tickles your fancy
   • Cons:
     • You are most likely to introduce security holes
     • Unless you've a bit of experience working with these technologies, this is likely to be the most time consuming

Further notes:

• It's probable that everyone will move to OpenID eventually and then the standard Google authentication should work everywhere
• The first option allows you to point a finger at Google if there is a problem with their authentication; the second option imposes more responsibility on you, but still allows you to say that you use a widely used solution if there is a problem and the final option puts all the responsibility on you
• Most of the issues revolve around session management - in case 1, Google does all of the session management and it is pretty invisible to the developer; in case 2, the session management is handled by the framework and in the 3rd case, you've to devise your own.