Hey folks! Sloan, DEV Moderator and mascot. I'm back with another question submitted by a DEV community member. 🦥
For those unfamiliar with the se...
For further actions, you may consider blocking this person and/or reporting abuse
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!
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: