The Different Pillars of User Authentication

Throughout the years, user authentication on the web has evolved, from Basic authentication to Session-based authentication to OAuth 2.0 with OpenIDConnect to Passwordless. As developers are increasingly required to become generalists, it’s important to have a solid mental model of the different authentication methods and protocols. If the bulk of your experience has been in front-end development, or you’re just learning about user authentication, this might be a good resource. I will also provide some great links at the end.

Basic Authentication

Since the introduction of the Web, the traditional way to authenticate users has been via a method called “Basic authentication”. This method of authentication is part of the HTTP (Hyper Text Transfer Protocol) authentication framework, and involves sending a user’s credentials (username, password) in plaintext, using the Authorization header.

As you can see, the credentials are concatenated using a colon and encoded using Base64, and sent with every request without a session or persistent login state.

Basic authentication does contain pitfalls you should consider.

  1. Base64 encoding can easily be reversed. Base64 is an encoding scheme, not encryption, and can be reversed using commonly available browser APIs. That, with the lack of encryption between the server and client, can allow a malicious user to capture and easily decode those credentials. HTTPS should be strictly enforced.
  2. Brute-force attacks. A malicious user may attempt to programmatically (use a dictionary attack (with or without mutations) or a traditional brute-force attack (with given classes of characters, e.g., alphanumeric, special, case (in)sensitive)) submit bogus credentials in an attempt to gain access to a user’s account. To mitigate such attacks, you can implement rate-limiting logic, such as exponential backoff, or lock down accounts after a certain number of failed login attempts.
  3. Credentials are sent with every request. Since credentials are sent with each request, there are more opportunities for interception.

Form-Based / Session Authentication

The more modern way to authenticate users has been via HTML forms and Sessions. (A process by which a server maintains the state of an entity interacting with it)

Credentials are submitted to the server either via FormData or in the request body as JSON, then validated and authenticated. A session is then generated, and a cookie containing the user’s session ID is created.

Things to consider when working with session-based authentication:

  1. Passwords must be properly hashed. Never store plaintext passwords. Use strong hashing algorithms like bcrypt, Argon2, or scrypt with an appropriate salt.
  2. CSRF attacks. If proper measures are not taken. For example, using a token on a state-changing web form that can be validated server-side, using Fetch Metadata headers, or ensuring the correct CORS (Cross-Origin Resource Sharing) headers are applied.
  3. Session cookies must be secured. Configure cookies with:
    • HttpOnly flag (prevents JavaScript access)
    • Secure flag (only transmitted over HTTPS)
    • SameSite attribute (helps prevent CSRF)
  4. Session management. Implement proper session expiration, renewal, and invalidation (especially on logout or password change).

OAuth

OAuth, or open authorization, is an authorization standard introduced around 2006. It was designed as a means of granting access to a set of resources, like user data from a third party. However, it is commonly used as a secure method of authentication, as many large organizations implement the standard as social logins. This allows developers to offload the implementation of authentication logic to a third party. Here’s how the flow works:

OAuth uses a combination of client ID, access token, and occasionally refresh token (typically a string of 32-64 hexadecimal characters) to verify the client from which the request is being made, and provide user data (name, email, profile picture) to your site. These tokens are then stored on the backend of your site, along with the provided user data for future use. While OAuth provides a secure and convenient way to handle authentication, it does come with some drawbacks.

  1. You are somewhat vendor-locked to the third party, as they manage the authentication flow.
  2. If the user decides to delete their account with the third-party, they will have no direct way of accessing their content on your site.

Typically, in large production applications, both traditional and social login methods of authentication are provided for this reason.

Multi-factor Authentication

MFA, or Multi-factor Authentication, is a relatively new way of authenticating users. The most common method is sending confirmation emails, which include a link with a token that verifies the user, or, more recently, a six-digit passcode sent via SMS text message or email. However, biometrics is commonly used in mobile apps. MFA is sometimes referred to as 2FA, or Two-Factor Authentication.

As confirmation emails and six-digit passcodes are the most common methods of MFA, I will focus on those implementations in the blog post.