Top 6 Web Authentication Methods
21 September 2023 • 5 min read
Share this post:
In the realm of web services, user authentication stands as the first line of defence, determining who gains entry to digital resources. This document serves as a comprehensive guide to the various methods employed in authenticating users within a web service. Before delving into these methods, it's imperative to distinguish between authentication, which asks, "Who are you?" and authorisation, which inquires, "What can you do?" This foundational understanding underpins the subsequent discussion on the techniques that safeguard digital spaces. There are several ways to authenticate users in a web service, which will be discussed in this document.
Firstly, it's important to understand the distinction between the following two terms:
- Authentication: Who are you?
- Authorization: What can you do?
Authentication precedes authorization. A user must be validated before being granted access to resources based on their authorization level. The most common method of authenticating a user is through a combination of a username and password. Once authenticated, different roles, such as admin or moderator, are assigned to them, granting them special privileges in the system.
Top 6 Web Authentication Methods
Now, let's explore the various methods used to authenticate a user.
HTTP Basic Authentication
Basic authentication, integrated into the HTTP protocol, is the simplest form of authentication. In this method, login credentials are sent in the request headers with each request:
"Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" your-website.com
Usernames and passwords are not encrypted. Instead, the username and password are combined using a colon (:) symbol to create a single string:
username:password. This string is then encoded using base64.
This method is stateless, meaning the client must provide the credentials with every request. It is suitable for API calls and straightforward authentication workflows that do not require persistent sessions.
HTTP Digest Authentication
HTTP Digest Authentication (or Digest Access Authentication) is a more secure form of HTTP Basic Auth. The main difference is that the password is sent in MD5 hashed form rather than in plain text, making it more secure than Basic Auth.
With session-based authentication (also known as session cookie authentication or cookie-based authentication), the user's state is stored on the server. It does not require the user to provide a username or password with each request. Instead, after logging in, the server validates the credentials. If valid, it generates a session, stores it in a session store, and then sends the session ID back to the browser. The browser stores the session ID as a cookie, which is sent with every subsequent request to the server.
Session-based authentication is stateful. Each time a client requests the server, the server must locate the session in memory to associate the session ID with the corresponding user.
This method uses tokens to authenticate users instead of cookies. The user authenticates using valid credentials, and the server returns a signed token. The most commonly used token is a JSON Web Token (JWT), which consists of three parts:
- Header (includes the token type and the hashing algorithm used)
- Payload (includes the claims, which are statements about the subject)
- Signature (used to verify that the message wasn't changed along the way)
All three parts are base64 encoded, concatenated using a period (.) and hashed. While encoded, anyone can decode and read the message, but only authenticated users can produce valid signed tokens. The token is authenticated using the Signature, which is signed with a private key.
Tokens do not need to be saved on the server-side; they can be validated using their signature. In recent times, token adoption has increased due to the rise of RESTful APIs and Single Page Applications (SPAs).
One Time Passwords
One-time passwords (OTPs) are commonly used for authentication confirmation. OTPs are randomly generated codes that can be used to verify if the user is who they claim to be. They are often used after user credentials are verified, especially for apps that utilise two-factor authentication. To use OTP, a trusted system must be in place, such as a verified email or mobile number. Modern OTPs are stateless and can be verified using multiple methods. While there are several types of OTPs, Time-based OTPs (TOTPs) are arguably the most common type. Once generated, they expire after a period of time. Due to the added layer of security, OTPs are recommended for apps that handle highly sensitive data, such as online banking and other financial services.
OAuth and OpenID
OAuth/OAuth2 and OpenID are popular forms of authorisation and authentication, respectively. They are used to implement social login, a form of single sign-on (SSO) utilising existing information from a social networking service, such as Facebook, Twitter, or Google, to sign in to a third-party website instead of creating a new login account specifically for that website. This type of authentication and authorisation is suitable when you require highly secure authentication. Providers like these have ample resources to invest in robust authentication systems, which can ultimately enhance the security of your application. This method is often coupled with session-based authentication.
In navigating the intricate landscape of user authentication, we've explored a range of methodologies, each with its unique strengths and applications. From the straightforward HTTP Basic Authentication to the robust Token-Based Authentication, each approach provides a toolkit for securing digital interactions. While One-Time Passwords offer an additional layer of security, OAuth and OpenID extend their scope towards seamless social logins. With this comprehensive understanding, we equip ourselves to make informed choices in safeguarding digital identities, acknowledging that in the evolving landscape of technology, authentication remains a cornerstone of digital security.
Share this post: