Make one resolution this year. Never write your own Authentication
Tags: webdev, security, beginners, authentication
Published: 2021-01-07 16:49:23

---
title: Make one resolution this year. Never write your own Authentication
published: true
description: I've seen a few blogs recently and tweets talking about authentication and handling passwords, it got me thinking...
tags: webdev, security, beginners, authentication
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/b1h58gzuumdlmuq4zlgq.jpg
canonical_url: https://jordanfinners.dev/blogs/make-one-resolution-this-year-never-write-your-own-authentication
---

# Contents 
1. [Intro](#intro)
2. [Why](#why)
4. [Options](#options)
5. [Summary](#summary)

# Intro <a name="intro"></a>

I've seen a few blogs recently and tweets talking about authentication and handling passwords, it got me thinking...

![NOOOO](https://media.giphy.com/media/3o7aD3BJA8vIGVaMw0/source.gif)

I'm going to start by caveating.
I'm all for learning how authentication works, if you're anything like me, I learn best by doing, so I've played around with authentication locally. But don't roll it out to production.

# Why <a name="why"></a>

Authentication is often the linchpin in the security of your application.
If we've seen anything over the last few years that data breaches of applications are only increasing, so application security has to be top of the priorities.
There is plenty to think about too about securing your application even before you get to your authentication system.

Thinking about writing your own authentication?

### What about cookies?
Cookies are plaintext, so you don't want to put anything secret in there and visible to anyone using the computer.
Is it using the Path argument to limit the cookie to your application?
Is it shared over subdomains?
It is Secure and only available over HTTPS connections?
What about Cross Site Scripting (XSS) attacks?

### Browser Storage
Okay so you've dealt with cookies. 
But maybe your storing data in browser storage - please never store anything sensitive or personal identifiable information (PII) in browser storage - have you ensured this is as secure as possible? e.g. using session storage rather than local.

### Rate Limits
What about limiting the number of requests? So that someone could not keep trying lots of different passwords.
How are you going to implement rate limiting? IP based; cookie based etc.
Do you lock out specific IP addresses after X attempts?
What about valid users who get locked?

### Password Security
Now let's talk about passwords. Are you going to set password requirements? If so, what are you going to make them?
Are you going to check if that password has been compromised using https://haveibeenpwned.com/ for example?
How are you storing the passwords? What happens if someone puts in a really long one, say generated by a password manager, is it going to get truncated? (I've seen this happen many times)
How are you hashing and salting the passwords? 
Please Please never keep passwords in plaintext.

### Database security
So, you're storing them in a database somewhere. 
How are you protecting that database to ensure its not breached?
If the database does get breached how are you limiting that to as few records as possible?
What about the network security around the database?

The list goes on, and on and on and on...
![The list goes on, and on and on and on...](https://media.giphy.com/media/j2wpZyLy2s70ul4TKo/giphy.gif)

# Options <a name="options"></a>

So, you're thinking alright, you've made your point, so what options do I have.

Well, fortunately you are in luck! There are now plenty of IDaaS (Identity as a Service) offerings.
They often have great free tiers, for example Azure B2C has 50,000 Monthly Active Users...FREE!

As with anything you need to find the best for your use case so I'll list a few below for you to check out:

[Auth0](https://auth0.com/#!)
[Azure AD](https://azure.microsoft.com/en-gb/services/active-directory/) 
[Azure B2C - Business To Customer](https://docs.microsoft.com/en-gb/azure/active-directory-b2c/overview)
[AWS Cognito](https://aws.amazon.com/cognito/)
[Firebase Authentication](https://firebase.google.com/docs/auth/)
[Okta](https://www.okta.com/)
[OneLogin](https://www.onelogin.com/)
[Magic](https://magic.link/)
[Twilio](https://www.twilio.com/authy)

These companies have _literal_ teams of people working to ensure that their authentication is secure and it's their business to make sure it is!

# Summary <a name="summary"></a>

In summary, authentication is hard! There is a lot to think about, my list here only scratches the surface and some of it you will still need to consider e.g. general database security.
But there are plenty of authentication providers you can use, even for free!

Stick to what adds value to your application/business! Leave the authentication to the companies whose job it is :D 

Let me know your favourite authentication providers below!

Happy building!

Photo by <a href="https://unsplash.com/@mr_williams_photography?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Micah Williams</a> on <a href="https://unsplash.com/s/photos/login?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a>