I've been researching this topic for days, but can't really find any solid reference surrounding this topic..

The idea is providing social login for mobile client apps. That's it. Sharing, accessing user's data, and other social features are not required.

Personally, I'd imagine (especially for cross platform games) that ideally you'd just open a web page where the authentication process takes place. This has the advantage of working across any platform without the need to bloat the app with unnecessarily bloated social SDKs. It also works consistently across platforms, give you test the web view presentation well enough.

Yet, most resource I keep finding keep pointing to SDKs to be used, or using OAuth APIs to initiate the auth process. This leaves me wondering if it was possible to securely implement web based auth flow on mobile clients...


Given a cross-platform app has a requirement to provide specific social login features (through Google+ and Facebook):

  1. Would it make sense to redirect the user to a special url within the app's website to perform the auth, then receive a callback from within the app itself?
  2. Are there any security (or otherwise important) constraints being compromised with such an approach that I'm not considering?
  3. Why isn't this approach popular (especially games)? The only game I've seen go with this approach so far is Pokemon Go on iOS. It shows a webview that logs you into Google+.


To understand the flow a little bit more, and grasp the context of web auth on mobile device, you can see here an overview of how it evolved in recent iOS and Android releases (2015):


In order to realize what I mean by bloated SDKs, just take a look for yourself at these examples:

Some issues that the previous SDKs introduce:

  1. Can't use IL2Cpp on Android (facebook SDK bug)
  2. Can't use Bitcode anymore (Google SDK disables that)
  3. Must introduce Cocoapods, which makes the build process less portable
  • 1
    Does your mobile app need bloated SDK's to authenticate through a web service that implements the ones you want?
    – JeffO
    Sep 2, 2016 at 20:43
  • @JeffO nah, that's the beauty, as I see it at least. The web service is my code, and I can easily extend my client app's code to open a web view that interacts with the web service. Hence, there are no added dependencies whatsoever. Moreover, this process scales as new social network providers are added on the backend.
    – Mazyod
    Sep 3, 2016 at 7:07
  • I've been researching the topic non-stop, and keep finding hints around the topic, but no definitive reference. For example, the first reference added above talks about web authentication in native apps, and how it may cause UX disruptions, unless the "Chrome Tab"/"SFSafariWebViewController" are used within the app, since they also provide the user credentials through safe keychain access.
    – Mazyod
    Sep 3, 2016 at 9:22

1 Answer 1


Disclosure: I'm an Auth0 engineer.

Point 1. In theory there's nothing wrong with your proposed approach, it sounds like will simplify things. Looking at it from the software development angle it's just another layer of abstraction that hides all the nasty details of authenticating with multiple identity providers.

From the authentication realm perspective I would classify that abstraction layer as a federation provider. Your application delegates user authentication to this one provider and doesn't really care how the user gets authenticated, as long as the provider result is successful the application trusts its outcome, that is, it trusts that the user in in fact who the federation provider says he is.

However, even though vouching for the user identity the federation provider does not actually deal with the actual exchange and validation of user credentials and just chooses to delegate this again to someone else (Google, Facebook, etc). Point 2.The only consideration around going with this approach is that you need to do it right...

This is very similar to what you would obtain from using third-party provider that already does all those other integration's for you, for example, Auth0 integrates with Google, Facebook and a bunch of other providers so whoever integrates with Auth0 only needs to write code against one API. I say API, because even if it's just Web based interactions you still need to comply with rules of those web based interactions.

There is one difference though, going with a third-party provider depending on your scale will ultimately cost you money, while rolling your own will only cost you time, resources and a sinking feeling that you may have forgotten something really obvious in terms of security. :)

Point 3. In relation to the usage in games, I honestly don't know, but in other areas I think is pretty common to go with this, the proof is that there are companies built on providing this exact service of simplifying the authentication against different sources. Maybe games due to their very specific UI requirements prefer to stay within the realms of the native experience.

  • Thanks for your thoughtful answer. You know, I did find auth0, but variable pricing always scares me off. I went ahead and implemented it myself, but honestly, it was a mistake. As you mentioned, it feels like there are too many loose screws
    – Mazyod
    Oct 16, 2016 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.