We cannot imagine a web application without the ability to authenticate to it, and the process of confirming that a person, organization, or website is who it says it is is known as authentication.
An authenticated user is able to access the platform and perform different sets of actions based on their privileges. It is a vital operation in web development, and having a fundamental understanding of authentication’s best practices really helps in becoming a good developer as well as acing the frontend system design interviews.
In the context of the web, usually authentication happens using an e-mail ID (unique identifier) and password. While this is a common trait, there are multiple different ways in which a user can be authenticated.
The login process can be divided into two different ways based on the way they login.
Password-Based authentication
In password-based authentication, a unique identifier, like a username and email address, is used along with a password. It can be secured further by adding a multi-factor authentication layer by receiving an OTP on the email or the phone number and verifying it.
This is a general authentication process that you will find implemented on many websites, as it provides two layers of protection. But the problem with this approach is that the user has to remember the password and keep it secure by using different combinations of alphabets, numbers, and special characters (we will read more about password best practices).
Password-less authentication
In password-less authentication, we free the user from the burden of remembering the passwords; rather, we make use of the software or application that only the user can access, and we pass a one-time password or magic link to it, using which the user can login.
Different ways of password-less authentication are:
- Phone number with OTP.
- Email address with OTP.
- Email address with a magic link.
- Email address and magic link, along with multi-factor authentication using a phone number and OTP, or vice versa.
These are a few of the ways in which the user can do a quick login without the need to sign up; this eliminates one step and provides easier access to the application.
There are also other options that are even more secure and password-less, as they take advantage of already-signed applications to authenticate the users, trusting that these applications are secured and have a large user base, like using Google, Github, or Facebook authentication.
You can also use different protocols for authentication that do not require a password.
OAuth
Open Authorization, also known as OAuth, is an authentication protocol that allows an application to authenticate using a token. Users receive these distinctive and secure tokens from the server, which they can use to further authenticate with the application.
Whenever you use any service of an application, you will see that you are provided an access token, which you can use to authenticate. These are the OAuth 2.0 tokens, which are recommended to be used as OAuth 1.0 has security vulnerabilities.
APIs from businesses like Facebook, Google, Twitter, and Microsoft currently use and implement OAuth 2.0, which relies on HTTPS for security. OAuth1.0a is more difficult to use because it requires the use of cryptographic libraries for digital signatures. However, since OAuth1.0a does not rely on HTTPS for security, it can be better suited for higher-risk transactions.
OpenId
An HTTP-based system called OpenId makes use of identity providers to confirm that a user is who they claim to be. Single sign-on (SSO) can be facilitated by a service provider through this straightforward protocol. This eliminates the need for the user to supply their password to any website other than the OpenId identity provider, allowing them to reuse a single identity that they have given to a reliable OpenId identity provider and log in to many websites as the same user.
OpenId is widely used because of its ease of use and password protection features. OpenId’s well-known identity providers include Yahoo!, Google, Facebook, and Stack Exchange.
As long as the identity supplier is reliable, OpenId is regarded as a safer and frequently superior option for non-enterprise situations.
SAML
Similar to OpenId, SAML also makes use of identity providers, but it is XML-based and offers greater flexibility. The foundation of SAML is browser redirects that transmit XML data. Moreover, SAML can also be started by the identity provider rather than only a service provider. This makes the procedure transparent by enabling the user to go between different sites and remain authenticated without needing to take any action.
OpenId and Security Assertion Markup Language (SAML) are frequently viewed as competitors. Version 2.0 is the most highly recommended version due to its robust security and extensive feature set.
While OpenId currently controls the majority of the consumer market, enterprise apps frequently choose SAML. This is typical because there aren’t many OpenId identity providers that are regarded as enterprise-class, which means that their methods for validating user identities don’t meet the strict requirements needed for enterprise identities. Intranet websites are more likely to employ SAML, and in certain cases, an intranet server is even used as the identity provider.
Applications such as SAP ERP and SharePoint (SharePoint via Active Directory Federation Services 2.0) have made the decision to use SAML 2.0 authentication as a frequently chosen method for single sign-on implementations in the past few years whenever web services and web applications require enterprise federation.
FIDO
The Fast Identity Online (FIDO) Alliance developed the Universal Authentication Framework (UAF) protocol and the Universal Second Factor (U2F) protocol to provide online authentication. U2F enables the addition of a second factor to currently used password-based authentication, whereas UAF concentrates on passwordless authentication. The public key cryptography challenge-response concept serves as the foundation for both protocols.
UAF leverages security technologies that are already on devices for authentication, such as Secure Elements (SEs), fingerprint sensors, Trusted Execution Environments (TEEs), microphones for voice biometrics, cameras for face biometrics, and others. The protocol’s purpose is to integrate various device capabilities into a shared framework for authentication. Web and native apps are both compatible with UAF.
Using a hardware token (usually USB) that holds cryptographic authentication keys and uses them for signatures, U2F enhances password-based authentication. The user can use the same token as a second factor for many applications. U2F is compatible with online apps. By looking for the stored authentication key using the website’s URL, it offers security against phishing.
Password best practices
- Enforce users to choose strong passwords of a limited length by allowing them to use all sorts of characters, even Unicodes. If possible, recommend auto-generated passwords that can be copied so that they can be stored.
- Set the minimum and maximum length of the password. The password should be at least 8 characters long and should be less than 64 characters long. Allowing a long password will make the user use a password that will be vulnerable. Not limiting the characters in the password could result in password denail of service attacks. When a long password is sent, the password hashing process will result in CPU and memory exhaustion.
- Never tamper with the password by truncating or appending anything to it; rather, use strong cryptographic algorithms to convert the password into hashes.
- Never compare passwords directly, but rather using the hash comparison methods that are usually inbuilt into programming languages or frameworks.
- While changing the password, make sure either the user is authenticated or ask them to provide the old password. Additionally, you can use multi-factor authentication to validate the user and prevent an attacker from changing it.
- If possible, exchange the password encrypted over the network.
- While performing a sensitive action, make sure to reauthenticate the user or do multi-factor authentication to avoid the cross-site scripting and cross-site forgery attack..
Login best practices
- Always hide the password on the UI while it is being input by the user and provide a way to view the password.
- Ask for proper error codes from the server to handle the authentication failure.
- Do not reveal sensitive information in the error messages; rather, show a standard message in case of any error or authentication failure, like “Invalid username or password!”.
- Restrict the number of login attempts in cases of consecutive failures. You can implement time-based restrictions as well and increase the time exponentially based on the failure count to avoid denial of service and brute force attacks.
- Have Captcha in place to avoid DDOS attacks. As the captchas can be bypassed, rather than being a preventative measure, using CAPTCHA should be seen as a defense-in-depth measure to make brute-force attacks more costly and time-consuming.
- Ensure all types of failures, such as login, password, or account lockout, are monitored and logged for further analysis.
The server generates and maintains a session once the user has authenticated. This helps the server remember how to react to subsequent requests and validate the users in each request. We will cover the session management separately.