Top 10 Social Login Considerations

There are A LOT of videos and articles to guide developers to include social logins in their mobile apps.  But most are superficial, covering the basic use-cases (most of them just the Login), but don’t discuss or explain, real-world implementation considerations.  

We’ve been building social login capabilities for a long time.  Below are some of the items we consider:

Why your app needs social login?  

This is easy:  Yes – because it makes life easy for your app user.  People don’t want to create accounts for every new app/service, and as an app developer, you’d like to know who’s using your creation. 

By now, you’ve followed all the steps, created an enterprise account with Google and/or Facebook and/or Apple and/or Twitter…, and you’ve created an app project instance, and you’ve gotten your auth token, and you’ve built a slick UI.  

When you click the ‘Google Login’ or ‘Facebook Login’ or ‘Apple Login’ button in your test app, it works!  

Done! Right?

Here are 10 things to consider after logging in:

1. Keep your Tokens fresh

The auth token in your app will expire.  Different providers have different timelines.  Sure, you can let your User’s token expire and force them to log in again.  

But a better user experience is to refresh the token automatically before it expires.  

2. Already logged in?

When a user opens your app, it will be a good experience to automatically check whether the user already has logged in to the app and automatically direct the user to an appropriate page based on the user’s login status. A user that has not logged in before will be directed to a page with generic content with the option to log in. A user that has already logged in will be directed to a page with custom content tailored to the user, possibly even the exact page where the user left off the last time the user used the app.

3. Offline mode 

It happens. Sometimes people and their devices end up untethered.  How will your app’s automatic authorization status check process function while the device is offline? Particularly in corner cases when the auth token is about to expire?  

4. What to do with the user auth data?

Each provider will pass back to the app the User’s public info (First name, last name, email, perhaps a profile picture, maybe other items). 

First, do you need to keep the user auth data? In general, the answer’s yes.  You want to keep the user data.  It’s why you added social login to your app in the first place.  But… now you’ve got PII (personally identifiable information), making CCPA and GDPR considerations relevant.  

If your app already uses a cloud data store, then adding the User Auth Data object along with authentication metadata to a storage location is the right way to go.  

5. Handling a user request to delete the user’s account in your app

You, as the app developer, will have to build functionality to delete all PII of the user submitting the request and still manage to keep the app’s functionality unbroken for other users of the app. Think in terms of a chat thread between 6 users and 2 of them have decided to delete their accounts. What should the user experience be when the other 4 users view their common chat thread and still maintain the context of the conversation.

6. Additional source data

Every social login provider passes the user’s public profile data.  Still, all providers have access to more information about the user – private data that can be shared upon request to the social provider, and of course, the user’s consent. Your app might have a use case where such additional information might be useful and in fact, be the differentiator for the app. For instance, Gender might be an important additional information a dating app might need or a user’s location for a food delivery app.

7. Do I need more than one social login provider?

Yes – it goes without saying, you’ll want “X” social providers.  A good number to start with is 3. 

From a development perspective, it means following all the steps X times, creating X enterprise accounts with Google and/or Facebook and/or Apple and/or …, creating X app registrations with the social authentication providers, getting X auth token, and augmenting the login page.  Not impossible, just time-consuming. 

8. What about account consolidations?

A user might have used your app for a few months authenticating themselves once with their Facebook account. After a hiatus from your app or maybe from all apps when on a digital cleanse/vacation or after switching to iPhone, a user might re-try your app and might want to use Apple login instead of Facebook login. How do you allow your user to carry forward all their activities from their previous incarnation as a Facebook user to their new avatar as an Apple logged-in user?

9. Other details

Is your integration with Social authentication providers capable of handling a user name change or a profile photo change? It’s a balance between caching the user name and/or photo in your app for faster rendering versus the data always being current with a performance penalty.

How quickly after a user’s password changes at the Social authentication provider will your app automatically log out a user? A user realizes their phone is lost and changes their password at either Google or Facebook or Apple. How soon will your app ‘log out’ the user? There’s a balance between how often you validate an auth token with the auth provider before allowing a functionality versus how quickly you let a user experience functionality.

How do you store other user attributes specific to your app alongside the user’s auth data? For instance, if you have to store a user preference like ‘Do not send me marketing email’ how do you associate that with the user’s auth data?

How do you normalize the data your app receives between different social authentication providers? Facebook sends your app ‘first_name’, Google sends your app ‘givenName,’ and Apple sends you ‘firstName’. 

Can your app handle both email address-based social login and phone # based social login?

10. Are you a Hero? Or Zero?

A closing thought (or consideration) for social login developers – social login is a ‘zero’ project.

Does your app need social login?  Yes (or at least, probably).  But consider this…

If you do it brilliantly, will you receive any accolades or acknowledgment?  No.  There is no prize for ‘best implementation of Google login.’

If you mess it up, will you be blamed?  Yes.  Definitely.  Users know how social logins are supposed to work – your implementation needs to work like it.  

Is social login the most interesting, value-added functionality on your app’s to-do list?  No, or at least I certainly hope not.  Your app’s value is in the clever value you’re creating and innovating, not in capturing user information.  

Therefore, I re-iterate:  Social login is a ‘zero’, a no-win task for developers.  It takes time and effort, and users will only notice it if it does NOT work.  

Can I buy, rather than build, a software Feature that addresses all the considerations above and lets me get on to the ‘hero’ functionality and capabilities where I can add value.  Yes.  Try Onymos now.