5 reasons to use third-party authentication instead of creating your own

Relying on third-party authentication services can be considerably easier, cheaper, and more secure than creating your own authentication. Here’s why.

You may have noticed that we don’t create credit card processing solutions here. We use what already exists, as we do for authentication services, and there are some good reasons for that:

1. Designing these systems is not our core competency. We’re good at researching languages and frameworks to design static analysis tools that help fix them.
2. In accordance with #1, development time spent on a payment gateway should be minimized.
3. We don’t want to absorb the financial and logistical overhead of storing credit card information and PII in compliance with PCI DSS (your company probably doesn’t either!).
4. If there is any sort of data breach on the third party’s side, it’s “their problem.” If there is a data breach on our side, it’s our problem, but the amount and type of data breached will typically be far less impactful.
5. The tooling that products like Swipe provide also includes user-level benefits, such as improved usability and performance.

You should rely on a third-party authentication provider too, rather than build your own. We’ll walk you through our rationale, but the evidence largely points out that outsourcing your authentication like you do with your credit card is, more often than not, cheaper, easier, and safer.

Let us be very clear up front. These systems are not perfect, and using them does NOT entirely absolve you of any security responsibilities. Many of the login providers have strong guidelines and best practices around implementing their systems securely. What these third-party authentication systems do is simply make the job significantly easier.

Now that we have that disclaimer out of the way, here are some reasons why you should consider outsourcing your authentication.

1. The cheapest way to protect PII is to not store it

Base-level authentication requires you to store at least a user name and a password hash. Email verification obviously requires email, and then two-factor authentication requires a mobile number or some other trusted contact information. You see, even if your authentication workflow is secure, you have a mother lode of PII waiting to be gobbled up by an eager hacker.

Here’s something crazy: Even if you’re diligent and use a relatively secure hashing algorithm like SHA-256 to encrypt and store your passwords, weaker encryption in other parts of your authentication flow can still make you vulnerable. This was Ashley Madison’s problem, among other things.

2. The easiest way to implement authentication is to not build it

When working on a new project, you might have a thought like “How many times in my life do I have to implement a ‘login’ flow, or a ‘reset password’ flow?” This is not glib or whiny. This is a valid concern. The focus of your staff should be maximized on your core competency, not reinventing the wheel.

Luckily, this is one of the problems that is solved when you switch to something like Google Sign-In. All the security, protection, and authentication happens on Google’s end, and users are protected by things like their two-factor authentication. Google basically passes you back a federated identity. All that’s left for you to do is authorize it on your system.

In addition to simple authentication, some tools like Firebase provide authentication as well as features like password reset and email verification.

3. Google and the others are probably better at building secure authentication systems than you are

If you’re not working within a vertical or an organization where managed data storage is an absolutely necessity, you can likely trust that companies like Google and Facebook have more resources at their disposal to keep your data safe than you do.

A very important note: Some third-party authentication systems are better than others! Be mindful of this as you move forward. For example, LinkedIn and Google seem to be best in show, while Twitter lags behind. Comparitech has a great comparison of the systems on their site.

4. If a breach DOES happen, the impact is far less significant

We should always be thinking about and planning for the worst, so what happens when there IS a data breach and you’re using Google Sign-In for your application’s authentication?

If the breach happens on Google’s side… well, that’s likely a much bigger problem. You can be confident in a few things:

1. Google has a fantastic security response team, likely to be matched by the other top federated identity providers.
2. Google’s users are not necessarily your users. If there is any sort of breach in Google’s user data, there will not be a 1:1 correlation between their users and yours. There’s even a nonzero chance that none of your users would be infected!
3. Google can typically move quickly to mitigate and resolve the issue, at no additional cost to you.
4. There are limited legal implications. You are likely protected from any direct litigation that might occur.

If the breach happens on your side, it’s still very bad. The good news is that, by outsourcing authentication, you have reduced the amount of PII that would have been compromised as a result of the breach.

5. For users, third-party authentication is often more trustworthy and usable

If I’m shopping for a deck of cards, I don’t necessarily trust “tomsmagicshopboston.com” but I do trust “PayPal.” The same applies to your authentication. Your users may not know it, but you’re asking them for a lot of trust when you supply a login. Most (but not all!) users will see Google, Amazon, Facebook, etc. and they will recognize a trusted brand that they know and are comfortable with.

Plus, the speed increase is wonderful for usability. Need to register? Click on the Facebook logo. Need to log in? Click on the Facebook logo.