Authentication Explained: From Passwords to Single Sign-On

Have you ever wondered what happens behind the scenes when you click the "Login" button on a website?

Whether you're signing into your email, accessing an online banking application, or using "Login with Google," a process called authentication is working in the background to verify your identity.

Authentication is one of the most fundamental concepts in software security, yet many developers confuse it with authorization. While the two are closely related, they solve different problems.

Authentication answers the question: "Who are you?"

Authorization answers the question: "What are you allowed to do?"

For example, when you log into a learning management system, authentication verifies that you are actually Sundaram. Authorization then determines whether you are a student, instructor, or administrator and what resources you can access.

Over the years, authentication has evolved significantly. Let's explore the most common authentication mechanisms used in modern applications and understand why each one exists.

The Early Days: Basic Authentication

One of the oldest authentication methods is Basic Authentication.

The concept is straightforward. A user provides a username and password, and those credentials are sent with every request to the server. The server checks whether the credentials are valid and grants access if they match.

While this approach is simple to implement, it has an obvious drawback: credentials are repeatedly transmitted over the network. Without HTTPS, an attacker intercepting the traffic could potentially obtain the username and password.

Because of this limitation, Basic Authentication is rarely used in modern consumer applications, although it still appears in internal systems and development tools.

Improving Security with Digest Authentication

To address the weaknesses of Basic Authentication, Digest Authentication was introduced.

Instead of sending the actual password, the client sends a cryptographic hash generated from the password and other request information. This means the real password never travels across the network.

At the time, this was a significant improvement. However, as authentication technologies evolved, newer approaches such as tokens and federated identity systems became more popular. Today, Digest Authentication is far less common than it once was.

The Rise of APIs and API Keys

As software systems became increasingly interconnected, developers needed a simple way for one application to identify itself to another.

This led to the widespread adoption of API Keys.

An API key is essentially a unique identifier issued to an application. When the application makes a request, it includes the key so the receiving service knows who is making the call.

You've likely encountered API keys while working with services such as payment gateways, mapping platforms, AI services, or weather APIs.

Although API keys are easy to implement, they primarily identify applications rather than individual users. For this reason, they are often combined with additional security mechanisms when sensitive data is involved.

Session-Based Authentication: The Traditional Web Approach

For many years, session-based authentication became the standard approach for web applications.

The workflow is familiar:

1. The user logs in with their credentials.

2. The server validates those credentials.

3. A session is created on the server.

4. The browser receives a session identifier, typically stored in a cookie.

5. Future requests include that session identifier.

Rather than verifying credentials on every request, the server simply checks whether the session is still valid.

This approach powers many traditional websites and enterprise applications even today.

However, as applications became distributed across multiple servers and cloud environments, managing server-side sessions at scale became increasingly challenging.

The Shift Toward Token-Based Authentication

Modern applications, especially APIs and microservices, often use token-based authentication.

Instead of storing session data on the server, the server issues a token after successful login. The client stores this token and includes it with future requests.

One of the most popular token formats is the JSON Web Token (JWT).

A JWT contains information known as claims, such as the user's identifier or role, and is digitally signed to prevent tampering.

Because the server doesn't need to maintain session state, token-based authentication scales exceptionally well across distributed systems.

This is one of the main reasons JWTs became popular in modern web applications, mobile apps, and cloud-native architectures.

Why Access Tokens and Refresh Tokens Work Together

If you've worked with JWTs, you've probably heard about access tokens and refresh tokens.

At first glance, having two tokens may seem unnecessary, but they solve an important security problem.

Imagine an access token remains valid for several months. If an attacker steals it, they could gain access to the system for months as well.

To reduce this risk, modern systems issue short-lived access tokens that might expire within minutes or hours.

When the access token expires, a refresh token can be used to obtain a new one without forcing the user to log in again.

This approach provides a balance between security and user experience.

OAuth 2.0: Logging In Without Sharing Passwords

As applications began integrating with external services, a new challenge emerged.

How could users allow one application to access another service without sharing their passwords?

This problem led to the creation of OAuth 2.0.

Consider the familiar "Login with Google" button.

When you click it, you don't give your Google password to the application you're trying to access. Instead, Google authenticates you and grants limited access through OAuth 2.0.

This delegated access model dramatically improves security because third-party applications never see or store your credentials.

Today, OAuth 2.0 is one of the most widely adopted security standards on the internet.

OpenID Connect: Adding Identity to OAuth

A common misconception is that OAuth 2.0 is an authentication protocol.

Technically, OAuth 2.0 is an authorization framework. Its primary purpose is to grant access to resources.

To solve authentication requirements, the industry introduced OpenID Connect (OIDC).

OIDC builds on top of OAuth 2.0 and adds a standardized way to verify user identity and retrieve profile information.

Most modern identity providers, including Google, Microsoft, and many SaaS platforms, use OIDC to authenticate users.

For developers building new web or mobile applications, OIDC is often the preferred choice for user authentication.

Single Sign-On: One Login, Many Applications

Think about your workplace.

You might access email, project management tools, HR software, documentation portals, and communication platforms throughout the day.

Without Single Sign-On, you would need separate credentials for each application.

Single Sign-On (SSO) eliminates this problem.

With SSO, users authenticate once and gain access to multiple applications without repeatedly entering credentials.

Beyond convenience, SSO also improves security by centralizing identity management and reducing password fatigue.

This is why SSO has become a standard feature in enterprise environments.

SAML vs OIDC: The Battle of Identity Protocols

When discussing SSO, two protocols dominate the conversation: SAML and OIDC.

SAML has been a cornerstone of enterprise identity management for many years. It uses XML-based messages and remains common in large organizations with legacy systems.

OIDC, on the other hand, was designed for modern applications. It uses lightweight JSON-based messages, integrates naturally with APIs, and works exceptionally well for web and mobile platforms.

While SAML continues to play an important role in enterprise environments, many organizations building new systems today prefer OIDC because of its simplicity and developer-friendly design.

Final Thoughts

Authentication has come a long way from simply sending usernames and passwords over the internet.

From Basic Authentication and server-side sessions to JWTs, OAuth 2.0, OpenID Connect, and Single Sign-On, each evolution was driven by the need for stronger security, better scalability, and improved user experiences.

As a developer, understanding these authentication mechanisms is essential because almost every modern application relies on them in some form.

The next time you click "Login with Google" or access multiple applications through a single company account, you'll know the technologies working behind the scenes to make that experience both seamless and secure.

Remember:

• Authentication verifies identity.

• Authorization determines permissions.

Mastering that distinction is the first step toward understanding application security.