What is Authentication (AuthN)?

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 a 3rd party service 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.

In this article, we'll explain what AuthN really means, the different AuthN methods, and discuss whether you should build your own AuthN system or use a provider.

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, AuthN 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 AuthN 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 AuthN methods in use today. They include: 

Username and password

This is one of the most popular and most widely used forms of AuthN. Users are identified by their unique username (sometimes email) and authenticated via a password. 

While this AuthN 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 AuthN . 

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 AuthN.

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 AuthN 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 AuthN 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.

Tokens

Tokens are often used to authenticate machine-to-machine and application-to-application interactions. One common example of tokens in use is API keys which can be uniquely generated and granted to users/applications to enable programmatic access to a system. 

There are various methods to generate, manage, and verify these tokens. However, no matter what method is used, only the issuer should be able to make new tokens and confirm existing ones for access.

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. 

AuthN 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 AuthN 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. 

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.

Implementing authentication

Typically, your choices are to either build authentication in-house or use a third-party library or vendor.

Build-it yourself

Developing your own authentication system allows you to tailor every aspect of the implementation to fit your specific needs. You also have full control over your users' data, which may be particularly important in highly regulated industries. But there are some downsides:

• 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.

So unless you're a complete expert in authentication or someone in your engineering team is, you’re better off buying an authentication solution.

Buying a done-for-you solution

Going with a third-party library or service reduces your upfront implementation and overall maintenance time and cost. It also gives you support for more AuthN methods 'out of the box' and a good security posture.

However, this approach does mean your application — and by extension, your business — will depend on an external party for a crucial part of your infrastructure. That’s why it’s crucial to go with a provider you can trust. 

For enterprise apps, consider using the fully-fledged AuthN platform from WorkOS. Integrating it into your app is quick and easy. You can use AuthKit, a fully customizable sign-in UI that automatically handles all your authentication flows, or build your own authentication UI and connect it to WorkOS using the Authentication APIs. 

Regardless of which method you use, you’ll get multiple authentication methods, including:

• Enterprise SSO with support for corporate identity providers like Okta, Microsoft Entra, and OneLogin.
• Social logins with support for OAuth providers like Google, GitHub, and Microsoft.
• Email and password authentication with password reset and email verification.
• Multi-factor authentication using authenticator apps and SMS passcodes.
• Magic authentication.

The bottom line

Authentication is just the starting point where users prove who they are to access your app. The next step is figuring out what they are authorized to do inside it.

Warrant simplifies this process. It’s a developer-friendly tool that helps you easily add different levels of access controls, like RBAC, ABAC, and ReBAC, to your app (both customer-facing and internal apps) — with just a few lines of code.

Start building with WorkOS