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.
Top comments (3)
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)
Thank you for the big picture perspective and thorough response!