In the wake of Facebook’s huge scandal surrounding how it handles personal data, a change to its app login API is leaving some apps nearly broken. It’s a reminder that building your own stack is probably best... but is it the best thing to do when it comes to logins and authentication? The API in question, Facebook Login, now has a tighter approval process. Apps that wish to use Facebook’s social login feature must adhere to "strict requirements." The company also says: “We will reduce the data that an app can request without app review to include only name, profile photo and email address. Requesting any other data will require our approval.” Tinder, a dating platform, is the most notable app borked by Facebook’s changes. Users reported being suddenly unable to use the app, which was quickly identified as a Facebook login issue. Gizmodo reporter Melanie Ehrenkranz then tried to create a unique profile via Tinder and was unable to do so, which could be indicative of users creating profiles en masse; an innocent DDoS, so to speak. Tinder’s issues suggest Facebook made changes without alerting partners. At the time I write this, it’s unclear what Tinder’s best path forward is; using it on desktop seems to work for some, but that’s not how most people use (or want to use) Tinder. [caption id="attachment_136636" align="aligncenter" width="750"] Facebook HQ[/caption]

Facebook, APIs, and SQL

This data/permissions maneuvering is likely not going to stop anytime soon for Facebook. It’s probably going to be echoed by others, too. So what’s a dev to do? First, we have to understand why social logins are handy. The cold reality is we simply haven’t emphasized bespoke accounts enough. A quick web search (we used multiple search engines) on writing a dedicated login portal for your app underscores this point; it’s really, really hard to find documentation or a tutorial on creating a login service from scratch. For the uninitiated, such a thing may even seem impossible. The nuts and bolts are simple enough – you need a SQL database tied to a web host, which is accessible via the app – but discovering how to do that is hard. Building your own login service is tough. Firebase, Google’s latest backend offering for developers, seems the most natural fit for doing so easily, but its authentication methods rely on Google, Facebook, Twitter, or GitHub for onboarding. Realm is another option, but there is no unique tooling for logins. And if you think checking the documentation for iOS or Android would help, think again. Cost is also a factor. Databases cost money, and if your service scales rapidly, who knows how much you may be spending for your free app. Then you’ll have to consider monetization, which is always tricky.

The Cold Reality

Technology moves fast. At some point, companies like Facebook saw an opportunity to leverage this difficult login workflow as a means to gather more data. It worked, too. And for a long while, everything seemed fine. And then the leaks, hacks, breaches and bad actors started surfacing. Responsible developers everywhere are asking what they can do to safeguard user data. This leaves everyone at a crossroads: do you learn how to spin up your own server for login and authentication, or roll with the social login punches? The answer isn’t easily reached. We always advocate for building your own services, but login and authentication are difficult. Searches alone lead you right back to social login solutions, which is the root of the problem. Le sigh. With the speed of innovation comes disruption, which most often translates into apps failing to capture a large audience. This is also what makes social logins attractive. Without an investment, little technical debt is accrued; still, Facebook and others are already causing developers to scramble. Avoiding social logins is possible, just as writing your own libraries so you can avoid third-party plugins is possible. It’s equally desirable, too, but the overhead is pretty intense for login and authentication. Like Facebook itself, many might just be unwilling to break up with social logins.