What is authentication (authN)?
Authentication (authN) is the process of verifying the identity of users or systems before granting access to resources, essential for ensuring security in applications. This blog explores various authN methods like passwords, multi-factor authentication, and biometrics, and discusses the trade-offs of building in-house or using third-party providers..
.webp)
If you're building an application, especially SaaS or B2B software, authentication (often abbreviated as authN) will likely be one of the first things you need to implement. Whether it's by asking for a password, using another identity provider like "Login with GitHub" or "Sign in with Apple," or sending a code to a user's phone, authentication checks if a user is who they say they are before giving them access to anything sensitive.
What is authentication?
Authentication is the process of validating the identity of an entity (typically a user or a machine) attempting to access a system. In other words, authentication is about determining who (or what) is attempting to access a system to decide whether to grant or deny that entity access.
A basic example of authentication is username + password login on web applications. A user who wants to log in to their account must provide their username and unique password, which an application server can then verify against what is stored in the system, granting the user access only if the passwords match.
Different authentication methods
There are many authentication methods in use today. In this section we will review the most popular options.
Username and password
This is one of the most popular and most widely used forms of authentication. Users are identified by their unique username (sometimes email) and authenticated via a password.
While this authentication method is straightforward to implement, it is notoriously prone to attacks mainly because users are likely to use simple passwords or reuse their passwords or across different systems.
Multi-Factor Authentication (MFA)
Multi-factor authentication (MFA) verifies a user’s identity using several methods. For instance, it might pair a standard username and password with a one-time passcode (OTP).
If an app has MFA enabled, it might ask users not just for their password but also for a code sent to their email or via SMS. This extra step helps safeguard accounts even if someone else gets hold of the password. A hacker might know the password, but they won’t get into the account without also having access to the user’s phone (for SMS) or email.
Single Sign-On (SSO) with an Identity Provider (IdP)
Most medium to large businesses that use SaaS apps use an identity provider to manage their employee data. An identity provider is a central service that stores employee identities and has the ability to verify them. SSO relies on these centralized providers to authenticate users once and give them access to multiple applications.
Biometrics
Biometrics uses distinct physical or behavioral traits to identify users. It's becoming popular for security because it's easy to use, especially with the fingerprint and facial scanners now common on laptops and smartphones. These devices have built-in sensors that quickly and securely capture, store, and validate biometric data right on the device, only sending the result of the validation (but not the biometric data) to applications so they can use that validation for authentication .
A well-known example of biometrics in action is Apple's Touch ID and Face ID, found on iOS and Mac devices.
QR codes
QR codes can be used as a quick but 'weak' form of authentication. As an example, a protected link can be encoded into a QR code shared with a trusted party. This ensures that only the trusted party can access the link.
However, it's considered 'weak' as the QR code and subsequent link can be shared with others and exploited without proper safeguards (i.e. time-based invalidation, single-use links, etc.). As such, only use QR codes sparingly (if at all) for authentication.
Magic links and One-Time Passcodes (OTP)
One-time passcodes (OTPs) are commonly paired with username/password authentication to enable multi-factor authentication. However, they can also serve as the primary authentication method.
For example, a consumer app can send an SMS to a user's phone containing a unique code that, when entered by the user into the app, grants them access to their account. This OTP authentication works assuming the user is the only one with access to the SMS.
Magic links are similar to OTP and rely on the fact that the user is in control of their email and phone and will be the only one to receive a 'magic link' that automatically logs them into their account.
Authentication (authN) vs Authorization (authZ)
Authentication is only half of the 'auth' equation. Once a system authenticates a user or entity, the next step is to figure out what that user or entity can do or has access to within the system.
Authorization occurs after authentication and determines what an authenticated user is allowed to do or access within a system. It answers the question, "What are you allowed to do or see?"
For instance, while one user might have authorization to view and edit all client files, another might only have permission to view them.
Authentication best practices
Prioritize passwordless authentication
Passwords have been a common authentication method for a long time, but they are plagued with security risks. Many people choose easy-to-remember passwords or use the same password on multiple sites. They can also be tricked into sharing their passwords through phishing attacks.
Besides these user-related issues, managing passwords is a hassle. You’ll have to securely store them and have strategies in place to recover locked accounts when users inevitably forget their passwords. Always opt for passwordless authentication methods like magic links, authenticator apps, or solutions that leverage biometrics like TouchID/FaceID or Windows Hello.
If you have to use password-based authentication, follow these best practices:
- Hash passwords before storing them.
- Pair it with another form of authentication like an OTP or biometrics.
- Don’t preset passwords. Instead, always require users to set passwords by themselves on their first login.
Implement account lockout policies
Implement account lockout policies to limit the number of failed login attempts a user can make before being locked out of an account. An approach to this is to set up a counter to track the number of failed login attempts for each user and block the user if they exceed the threshold within a certain time.
Your policy should balance security and usability. Setting the threshold too low can lead to frequent lockouts, frustrating legitimate users. Find a balance that provides security without significantly affecting user experience.
Implement secure session management
Because session data can be sensitive, it’s important to properly manage sessions. Here are some best practices to follow:
- Implement session timeouts: Session timeouts automatically terminate a user session after a certain period of inactivity. They help prevent unauthorized access when a user leaves a device unattended.
- Use secure cookies: Sessions are typically managed using session tokens, which are unique identifiers assigned to users when they log in. Set cookies with the Secure, HttpOnly, Max-Age, Expire, SameSite, and Path attributes.
- Invalidate sessions properly: Ensure that sessions are fully invalidated and cookies are cleared when a user logs out or when their sessions expire.
Don’t implement your own authentication system if you don’t have to
Creating your own authentication from scratch usually involves significant risks and challenges that often outweigh the customization and control benefits. You must account for all potential security vulnerabilities and attack vectors. Any oversight or error in the design or implementation can introduce serious security weaknesses, leaving your system vulnerable to attacks. Some of the pitfalls include:
- Security vulnerabilities: The biggest risk of building your own system is the potential for security flaws. Unlike commercial or open-source solutions that have been
battle-tested, a homegrown system is more likely to contain undiscovered vulnerabilities. Also, the responsibility to respond to and patch vulnerabilities quickly falls entirely on you. - Resource intensive: Requires significant upfront and ongoing investment in terms of development time, security expertise, and maintenance. This includes keeping the system updated against new threats and managing scalability.
- Longer time to market: Developing a custom solution can significantly extend the time it takes to launch new products or features, as substantial engineering time is needed to ensure the authentication system is robust and secure.
Instead of building your own system, use well-supported libraries and frameworks to handle authentication, such as OAuth 2.0, OpenID Connect, or SAML. Also, consider using managed authentication services provided by platforms like WorkOS.
.webp)

.webp)


.webp)
.webp)

_.webp)






.webp)



.webp)

