One of the most common reasons why software developers and architects add a backend to their frontend(s) is the need for user management. In order for user management to work, signup and sign in functionalities are key. In the past, most applications had their own system for authentication and thus every user needed to actively create an account by providing email address, password and other information. Not only is this cumbersome to the user but also notoriously insecure. Many users will use the same password everywhere, known as password fatigue, and with every party that has the password stored, the probability grows that it is stolen.
As of late, more and more services offer “social login” (“Login with Facebook”, “Login with GitHub”, etc.) which improves user experience by letting users signup/login with their already existing account on a popular platform.
A simple way of implementing social login is by using CloudRail, an API Integration Solution for various platforms that makes it easy to connect to cloud storage, payment, email, sms, location services and, last but not least, implement social login. This article thus uses CloudRail as an example but strategies as well as pros and cons are the same no matter what you use.
Many social login strategies rely on OAuth to have the user authenticate and then authorize an application to access their account. After, the application can retrieve information about a user’s account to identify them or create a new profile. There are three possibilities how one can distribute the functionality needed for social login:
- Do authentication and authorization in the frontend and information retrieval in the backend (The Good)
- Do both in the frontend (The Bad)
- Do both in the backend (The Ugly)
We’re going to discuss each strategy and outline pros and cons.
The Good
How it works
Let’s assume we have a Node.JS server with some database as our backend and an iOS and an Android app in the frontend. We want our users to be able to signup/signin with Facebook, Instagram, GitHub etc. in the app and keep track of user accounts in the database connected to the backend. This strategy requires the addition of the CloudRail SI SDK in the backend and the two frontends, choosing the appropriate SDK for each platform. The authentication and authorization happens in the frontend and after that, the credentials obtained are sent to the backend.
In the backend, the credentials are used to directly access user information. The following code samples for Android and Node.JS illustrate that:
Frontend:
Backend:
A full example can be found here.
Pros and Cons
Pros:
Cons
- Client Secret is not very safe in the frontend (even though it is not uncommon practice to have it there)
- CloudRail SI SDKs required for all platforms involved
The Bad
How it works
Let’s assume we have a backend where we don’t want to integrate CloudRail SI or are using a “Backend as a Service” provider that does not support social login. You might be tempted to do everything in the frontend:
Frontend:
This looks nice and easy, doesn’t it? The problem is though, that this approach is highly susceptible to manipulation! An attacker could simply send someone else’s identifier to the server to impersonate them. This cannot happen with the first approach since the credentials sent to the server are cryptographically secure (at least if the respective service API is secure).
In short, don’t use this approach!
The Ugly
How it works
If we have a backend where we can integrate the CloudRail SI SDK but cannot use it in the frontend (e.g. because there is no CloudRail SI SDK for the language used) we can do the whole process in the backend with minimal interaction with the frontend. The key challenge is that OAuth is a multi-step process during which two different requests from the frontend will reach your server. As the server might consist of multiple instances and we cannot guarantee that both requests will land on the same instance, we have to leverage the database for the authentication process.
The following example outlines just that and merely requires the frontend to be able to follow redirects sent from the server. This is natural for websites and easy to implement for other frontends.
Backend:
This is more complicated than the first approach (“The Good”) and we thus call it “The Ugly” but it has its benefits.
A full example can be found here.
Pros and Cons
Pros:
- Client Secret safe in the backend
- CloudRail SI SDK only needed in the backend
- Scales well for different frontends
Cons:
- Not so easy to implement
- More invasive to the server
Summary / TLDR
We’ve seen three different approaches to social login from which only two can be safely recommended. The namings are tongue-in-cheek but distinctive of each approach. Depending on what a developer is willing and capable of changing, a different approach might be preferable. We have seen that social login must always involve the backend, pure frontend implementations are insecure. This is in particular an issue for users of BaaS, since they depend on their provider’s support for social login.