The typical advice is not to roll your own auth, on the surface level it seems fairly simple enough, all you need is an email, password and a user id, the rest is history. However, it quickly becomes a project itself. It’s not that you can’t, it’s that you probably don’t want to. Authentication is a side effect of having users, your users need accounts which need to be accessible and secure, hence your app needs authentication. However, you most likely don’t want to build authentication, it’s merely something you need. Your time would be much better spent actually developing the product.
Alas, you might want to roll your own regardless, so these are some of the things you’ll need to keep track of:
Emails
There will need to be some form of communication between the software and the user, and this is usually done via an email address.
Email validation
You’ll need to validate that an email exists and that the user has access to it. The only way to truly validate an email is by sending a code or url key and requiring the user to verify by input. Regex won’t cut it. The following are all valid email addresses as defined in RFC2822.
user@[192.168.2.1]"()[]:,;@\\\"!#$%&'-/=?^_| ~.a"@example.orgpostmaster@[IPv6:2001:db8::1]"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
Specifically an email can contain any string, followed by an @, then a domain, which can also be a direct IP address. Although, in practice many email providers have stricter requirements that this.
Passwords
It’s also important to make sure that users have a strong enough password to prevent the chances of brute force attacks. With a modern and secure password hashing algorithm, like argon2, an attacker guessing the hash should be practically impossible. It would be wise to prevent extremely common passwords from being used like ‘1234’ or ‘password’.
The ideal scenario is that everyone uses a secure password generator, like bitwarden, but that is hard to enforce. It’s important to a strike a balance as users default to picking simple passwords especially when frustrated.
Email & password change / recovery
The user will need the ability to change their password, almost always by sending a code or link, securely, to their email. This is also used if a user forgets their password. It’s important that this is secure as it can be used by attackers to reset a user’s password and gain access to their account.
Combined identities
You might want a way to join identities. A user might have initially signed up using their email and password, but now they want to add their Google account for quicker login, both identities will need to be associated to a single user. The identities are separate and have separate sessions and details but share a user.
Session
A session is created when a user signs in, it uniquely identifies them across requests and interactions. The session id is the form of authorization that the user uses after signing in, as such it is of extreme importance and should only be accessible by the user and the service. Session ids must have enough randomness to prevent guessing, at least 64 bits. It will need to be stored securely and only transmitted over a secure connection to prevent session hijacking.
MFA
Multifactor Authentication (MFA) is when a user is required to present more than one type of evidence in order to authenticate on a system. Despite your best efforts, users are susceptible to choosing weak passwords, because they are easy to remember or because they didn’t have access to their password generator at that time.
However, MFA can quite often lead to user dissatisfaction, leading to them disabling it. This would defeat all your efforts to make it more secure. You could enable threat based MFA, such as only requiring it on new browsers or devices, or maybe using geolocation.
Email verification
The simplest implementation of MFA, from a developers perspective, is email verification. The user signs in and is sent either a key or a url to confirm that they are the owner of that email. This can help mitigate attacks where only a user’s password was compromised. It also lets you inform users, if there have been failed attempts on unrecognised devices.
Passkeys
A passkey is a password-less authentication method that uses the security features of devices, such as FaceID and Touch ID. They are more secure and easier to use than most methods of authentication.
It’s unlikely, though, for an app to only use passkeys, since the user might not have access to their device, so passwords are typically required as well.