Web-based vs Native Social Login on Mobile Clients

Question

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...

Question

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+.

References:

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):

https://www.pingidentity.com/en/blog/2015/06/19/mobile_os_developments_native_application_authentication.html

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

• facebook SDK
• Google+ SDK

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

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.