Sloan's Inbox: How would you approach designing an authentication system from scratch?

Hey folks! Sloan, DEV Moderator and mascot. I'm back with another question submitted by a DEV community member. 🦥

For those unfamiliar with the series, this is another installment of Sloan's Inbox. You all send in your questions, I ask them on your behalf anonymously, and the community leaves comments to offer advice. Whether it's career development, office politics, industry trends, or improving technical skills, we cover all sorts of topics here. If you want to send in a question or talking point to be shared anonymously via Sloan, that'd be great; just scroll down to the bottom of the post for details on how.

Let's see what's up this week...

Today's question is:

How would you approach designing an authentication system from scratch? I know there are libraries for handling this, but I'm hoping to learn more and am curious if anybody has any good advice or resources for this. Thanks!

Share your thoughts and let's help a fellow DEV member out! Remember to keep kind and stay classy. 💚

---

Want to submit a question for discussion or ask for advice? Visit Sloan's Inbox! You can choose to remain anonymous.

Comments

[Phil Ashby]

As ever with open questions like this "it depends" 😁

TL;DR - It's less a technology question than a business risk management one! The technology often falls out of understanding the bigger picture. Also I'm an architect, so big pictures are my go to. The below may be very over the top for your question!

I would always start with ensuring a good understanding of why an authentication system is required, in particular:

1/ Information protection needs eg: multi-tenant segregation, PCI Card Data, PII
2/ Reputation / people trust protection needs eg: social media platform, security disclosures
3/ Attribution / tracking needs eg: billing data, non-repudiation

This understanding will guide you in creating the right user experience (UX): eg: should the whole system be behind authentication, or just some of it? What about a demo area, test accounts? Do you have other systems / services that need to share authentication?

Your existing (and/or predicted) business relationships will also guide the UX, perhaps the system federates with other parties in B2B services, or perhaps you only provide B2C single-person services?

Your understanding wil also provide guidance on the use of single or multi-factor authentication (regulation such as PCI-DSS, HIPPA or SOX2 will certainly specify multi-factor!)

Now you know why and some of how authentication should work from the outside, you are in a good place to look at the the threats the system might face, what class of attacker may be interested in it (eg: foreign intelligence services - lucky you[!], organised crime, hacktivists, bored teenagers, etc.), their capabilities (eg: funds available for bribes or DDoS network rental, likelihood of violence / physical threat against staff / customers, technical ability / reliance on existing tools, etc.) and their motivations (eg: financial gain, reputation manipulation, national "protection")

With your UX design and threat model in hand, you can now go about designing the right authentication solution to provide the security controls / mitigations needed to address identified threats, UX needs and regulatory / business processes. I would start by choosing appropriate technology (encryption algorithms, key strengths, secure storage, disaster recovery, federation [OIDC, SAML], multi-factors [OATH, SMS, App]), documenting processes (are there humans in the loop [support / IT] and why? how should account creation, deletion, credential recovery / reset work [codes, other devices]? ) and documenting auditing mechanisms (will logs be needed for legal purposes [non-repudiation]? how long are logs held? who has access?)

Congratuations if you made it this far! Even if you don't build your own solution (you could after all choose to outsource some risk and most technology choices to an authentication provider but you still need to know why and what the risk is / trade offs are!), the considerations above are mostly managing business risk rather than making technology decisions or designing anything terribly new. I wanted to emphasise this as I find a lot of organisations / people approach authentication from a technology viewpoint and miss the point of it existing.

Good luck if you do roll your own solution - and do please look at the technical articles, blogs and security incident reports(!) from the big players in this space: Auth0, Okta, Microsoft Entra ID, Amazon Cognito, Cisco Duo, Ping Identity, et al)

[Jess Lee]

Thank you for the big picture perspective and thorough response!

[Kevin Naidoo]

The whole process requires a lot of grunt work, which can be tedious and long, so hard to describe in a comment but it's fairly easy to build an auth system. Here are the key components:

1. When a user posts the login form, you need to have some sort of auditing to prevent abuse and hacking attempts. Collect their last login, device info, location (or country), etc...
2. Password hashing, any stored password should be hashed with a strong algorithm. Bcrypt is a common one.
3. 2 factor auth. Either send an SMS or email or use an authenticator service.
4. Emails. Welcome, forgot password, etc...
5. Oauth. People usually use Gmail, Facebook, and so forth to log in.
6. RBAC. Once they log in, you need some kind of permission system to control who has access to what.
7. Sensitive information protection. Send an OTP or ask the user to re-enter their password when they try to do something "destructive" for lack of a better word. Example: updating their password from their profile or changing their OTP number.
8. Essential screens: Register, Login, OTP confirm screen, Forgot password, Reset (Forgot sends them a link and they click to land here and set a new password), Verify account (after registering they need to enter an OTP or click a link in their email).