Beyond the Password: Modern Authentication Explained

Authentication is simply the act of proving who you are when accessing a resource on the internet. At its most basic, it begins when a user signs up and creates a password, which is then used to verify their identity every time they log in. Over time, this simple model is extended to handle more secure, reliable, and flexible ways of authenticating users.

Password based Authentication

When a user signs up or log in, a password get stored into the system which raise a lot of security questions: How are your passwords stored? What if the system’s database is compromised?

So let’s dive into how passwords should be handled when building a basic authentication flow.

• Passwords should be stored in the user table and mapped to a unique identifier such as a username or email, but they should never be stored as plain text. Instead, they should always be stored as a hashed value.
• Using hashes introduces a simple problem, for a specific algorithm — the same password will always produce the same hash, for example a common password like password will always give the the same hash 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 when using sha256.

$ echo "password"
password

$ SHA256("password")
5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8

• These well-known hashes can be easily recognized using pre-computed lists, allowing attackers to reverse-engineer common passwords — Rainbow Table Attack.
• To prevent this, a salt can be used. A salt is a randomly generated string created when a password is set or updated and is stored alongside the user’s record and hashed password, e.g.:

id | username | salt | password_hash | ...

• The final stored value for password_hash is created by combining the password with the user’s salt before hashing it:

password_hash = hash(password + salt)

• This ensures that even common passwords result in unique hashes and cannot be reverse-engineered without knowing the original password.
• When a user logs in, the same process is repeated to verify a login. The entered password along with the user’s salt is converted to a hashed value and the result is compared to the existing password_hash to verify the user’s identity.

From Passwords to Ongoing Access

Relying only on passwords would make browsing the web extremely frustrating. Imagine having to enter your username and password every time you want to watch a movie on Netflix, check your messages, or simply refresh a webpage. Clearly, that is not how modern applications work.

The reason you don’t have to log in again and again is because after a successful login your browser stores a small piece of information that helps the server recognize you on future requests.

When you log in for the first time, the server doesn’t just grant access; it also returns a special value to the browser. This value is saved in the browser’s local storage and used on subsequent requests, allowing the server to verify your identity without needing your password.

Imagine this as the temporary wristband given to individuals when entering a private event. The wristband grants you temporary access for the day to different areas within the event, without requiring you to show your ticket again.

At this point, you might be wondering:

• How does the server create this special value?
• How does the server know which user it belongs to?
• Why use this approach at all — why not just store the username and password directly in the browser?

Let’s start with the simplest one: why not store usernames and passwords directly in the browser? Because if someone gains access to your browser — through device access or a scripting attack, they would immediately have full control over your account. Since passwords are long-lived secrets, they should never be stores directly in the browser.

In contrast, the value returned after login is limited in scope and lifetime. Even if it is stolen, it typically allows access only for a short period and does not reveal your actual account credentials.

So where does the server keep track of this information, and how does it validate future requests? This is where two common approaches come into play:

• Session based authentication
• Token based authentication

Session-based vs Token-based Authentication

Session-based Authentication

In session-based authentication, when a user logs in successfully, the server creates a session for that user and generates a unique session ID. This session ID is stored by the server, in either a database or in-memory store.

The server then sends the session ID back to the browser in a cookie, which the browser can use for future requests. Using this approach, the user needs to enter their password only once during login or again when the session expires.

With this approach, the actual user data and authentication information remain on the server. The session ID stored on the browser is only a temporary identifier.

But what happens if someone steals the session ID? Since a session ID represents an authenticated user, stealing it can temporarily grant access to the account. To limit the impact, the backend system must provide mechanisms to invalidate existing sessions, such as a Log out everywhere option which terminates all active sessions.

Pros

The main advantage of session-based authentication is that it allows long-lived sessions without exposing your permanent credentials. This reduces the risk of losing access to an account permanently.

For example, on platforms like Facebook, Netflix, or Gmail, you typically log in once and remain logged in for a long time on the same browser, without needing to re-enter your credentials.

Cons

The main drawbacks are infrastructure cost and operational overhead:

• Developers must maintain a separate storage solution to keep session IDs mapped to user accounts.
• As discussed above, systems need a reliable way to invalidate all active sessions for a user, such as a Log out everywhere feature.
• Every API call to the server requires an additional DB lookup to validate the session ID.
• Managing session storage introduces further challenges, including cleaning up expired sessions and synchronizing session data across regions.

Token-based Authentication

Given the operational complexity of stateful authentication, many systems move toward a stateless approach. This is where token-based authentication comes into play.

In token-based authentication the information about the user’s identity is stored in the token itself — it is not a random hashed string. Instead this special kind of token contains information in plain site, this special token is a JSON Web Token (JWT) and usually called an access token.

A JWT relies on Digital Signatures, which allow data to be signed using a secret key (e.g. HS256 algorithm). The signature enables the server to verify that the token was created by a trusted source and has not been tampered with.

A JWT is made up of three parts:

• The header
• The payload
• The Encrypted signature

The header contains the metadata about the token which usually includes the encryption algorithm used to create the signature.

The payload contains the actual data about the user, represented in JSON key-value pairs.

The signature is created by encrypting the header and the payload using a secret key:

SIGNATURE = ENCRYPT( HEADER + PAYLOAD )

JWT = HEADER + PAYLOAD + SIGNATURE

A complete JWT ends up looking like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0
.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

Here each part of the token is base64-encoded and separated by a dot (.) .

You can view the decoded header and the payload of the above token by pasting the token in the website: jwt.io. The website also shows if the token’s signature is valid or not by pasting the secret key used for creating the signature.

The token is valid and was signed by the secret key: a-string-secret-at-least-256-bits-long

Here is something interesting to try: if you modify the JSON payload slightly, re-encode it, and replace it in the token, the signature will no longer be valid — even if you use the same secret key. This is because the signature is created using both the header and the payload.

This ensures two important things:

• The token was created and digitally signed by the server when the user mentioned in the payload authenticated.
• And more importantly — once a token is created, the token’s header and payload cannot be altered to create a fake or tampered token.

However, tokens can still be stolen and reused to impersonate a user while they remain valid. Unlike sessions, there is no built-in way to invalidate all issued tokens at once.

Because of this, tokens are typically short-lived and include an expiration time. Once expired, the server must reject them. This expiration is stored directly in the token’s payload:

{
  "sub": "123456789",
  "name": "John Doe",
  "admin": true,
  "iat": 1765221761,
  "exp": 1765225361
}

Here, the exp field specifies when the token will expire. The server uses this value to reject any token that is no longer valid.

But what if an attacker steals the token and changes the expiry time to something far in the future? Well, that would require modifying the payload and as mentioned above, doing so would invalidate the signature and cause the token to be rejected by the server.

Imagine JWTs as the modern banknotes — where we can easily see the information: its value, the denomination, the currency and the issuing authority. All information is clearly visible to everyone but if it is tampered with or faked, its of no use.

This naturally raises another question: what happens after a token expires? Do users need to log in again? Short answer — No.

If an access token expires every hour — which is a common practice in token-based authentication — forcing users to re-enter their username and password each time would be impractical.

This is where a refresh token comes into play.

Refresh Tokens

A refresh token is a long-lived token whose sole purpose is to obtain a new access token. But how does that help, and what happens if a refresh token itself is stolen?

Well, refresh tokens are conceptually similar to the session IDs discussed earlier in the session-based authentication:

• They are random, opaque strings and do not need to be JWTs.
• They are also stored and managed by the server, typically in a database.
• They are long-lived compared to access tokens.
• The server should have a Log out everywhere mechanism to revoke all active refresh tokens associated to a user.

But this is how refresh tokens differ from session IDs:

• Using a single session ID that is valid for months can introduce potential risks. In contrast, refresh tokens are long-lived compared to access tokens but still have an expiration ranging from a few hours to a day.
• When using session IDs, every API request required a database lookup request to validate the session ID. On the other hand, in token-based authentication, database access is only required when an access token needs to be refreshed. Once an access token is issued, no additional database lookups are required until it expires.
• Not every system needs refresh tokens. In scenarios that require higher security — such as banking websites or government portals, users are often required to enter their credentials on every login. These systems typically rely on very short-lived access tokens and do not issue refresh tokens at all.
• A common best practice with refresh tokens is to rotate them — since a refresh token’s purpose is to obtain new access tokens, it can be rotated each time a new access token is issued.

So finally here is a typical refresh token authentication flow:

1. The user logs in using their username and password (credentials).
2. After successful authentication, the server generates two tokens: an access token and a refresh token.
3. The server returns both tokens to the browser.
4. The browser stores the access token and refresh token securely (often using different storage mechanisms for each).
5. The access token is sent with every authenticated request to prove the user’s identity.
6. When the access token expires, the client sends the refresh token to the server to request a new access token.
7. The server validates the refresh token and if valid, issues a new pair of access and refresh tokens.
8. The old refresh token is invalidated, and the client updates its stored tokens with the newly issued ones.

This approach allows users to stay logged in without repeatedly entering their credentials, while still limiting the damage if any token is compromised.

Third-Party Login: OAuth and OIDC

So far, we’ve seen that authentication usually starts with entering a username and password, and much of the complexity that follows is about reducing how often users need to re-enter those credentials. Another common way to achieve this is by using trusted third-party login providers to establish a user’s identity.

Some of the most widely used third-party providers support OAuth and OpenID Connect (OIDC), including Google, Facebook, and Microsoft. For simplicity, we’ll use Google as the example in this section.

You’ve likely encountered Google-based login in many applications. The flow usually looks like this: you click the Sign in with Google button and are redirected to a Google login page. After signing in, you’re asked to grant access to basic account information — typically your name, email address, and profile image. Once you click Allow, you are redirected back to the original application.

Under the hood, this flow is powered by OAuth and OIDC. OAuth provides a standardized way for an application to request access to a user’s data. OIDC builds on top of OAuth to add a verified identity layer, allowing the application to reliably know who the user is.

Together, OAuth and OIDC enable third-party login by combining delegated access with secure user authentication.

But what really happens behind the scenes? What information is exchanged between your application and Google? Lets walk through the flow step by step.

• When you click Sign in with Google, the frontend redirects the user to a Google-hosted consent screen. This redirect is made to Google’s authorization endpoint and includes a client_id, which uniquely identifies the application requesting access.

GET https://accounts.google.com/o/oauth2/v2/auth
  ?client_id=YOUR_CLIENT_ID
  &redirect_uri=...
  &response_type=code
  &scope=...
  ...

• After the user reviews the permissions and clicks Allow, Google generates a short-lived authorization code (auth code) and redirects the user back to the application’s configured callback URL, attaching this code to the request.

Redirect: https://yourapp.com/callback?code=AUTH_CODE

• This auth code is similar to something we have already seen before — the session ID or the refresh token — but it is extremely short-lived and can be used only once. Google temporarily stores this code and associates it with the application’s client_id.
• Once the frontend receives the auth code, it forwards the code to the application’s server. The server then makes a second request to Google’s token endpoint. This request happens server-to-server over HTTPS, allowing the client_secret to be safely included.

POST https://oauth2.googleapis.com/token

  code=AUTH_CODE
  &client_id=YOUR_CLIENT_ID
  &client_secret=YOUR_CLIENT_SECRET
  &redirect_uri=...
  &grant_type=authorization_code
  ...

• Google validates the auth code against the client_id and client_secret. If everything checks out, the auth code is invalidated and deleted. Google then issues an ID token (JWT) along with a pair of access and refresh tokens and returns them to the application’s server.

The access and refresh token returned by Google are not important for the authentication process — these tokens can be used to get access to more Google services based on what permissions the client has.

• The ID token contains verified identity information about the user — such as name, email address, and profile picture. The server can use this information to create or look up a user record and then issue its own access and refresh tokens, following the same token-based authentication flow described earlier.

A natural question here is: why doesn’t Google directly issue an ID token right after the user clicks Allow? Why go through the extra authorization code step at all?

The reason is security. If Google were to return an ID token directly to the frontend, that token would be exposed in the browser. Any malicious script running on the page could read it and reuse it.

More importantly, at that point Google would have no strong guarantee that the application receiving the token is actually legitimate. The authorization code flow solves this by requiring a second, server-to-server exchange. Only the application’s server — where the client_secret is securely stored — can exchange the authorization code for tokens.

This step proves to Google that:

• the application is who it claims to be (via the client secret), and
• the authorization code was issued specifically for that application.

By keeping the client secret out of the browser and requiring this verification step, Google ensures that ID tokens and access tokens are issued only to trusted servers, not directly to potentially compromised frontends.

This is why the authorization code flow is the standard and recommended approach for OAuth/OIDC-based logins.

API Key Access

When accessing a system’s APIs in an automated or programmatic way, logging in with user credentials or using user-bound tokens is often not practical. There is no interactive user, no browser, and no login flow. In such cases, systems provide API keys as a way to authenticate in an automated way.

For example, you can create API keys and secrets in AWS to access cloud services via code, or generate API keys in OpenAI to call its APIs programmatically.

The way API keys work is not fundamentally different from what we’ve already discussed. An API key is a long, random string generated by the system and stored on the server, mapped to a user or application — similar to how a password is associated with a user account. In that sense, an API key can be thought of as a system-generated password.

Just like passwords, API keys should not be stored in plain text. Instead, their hashed values are stored in the database. This is why many services show an API key only once at creation time and ask you to copy it immediately, because the system itself does not retain the original key — only its hash.

A major risk with API keys is that if one is leaked — for example, an OpenAI API key — anyone who obtains it can make requests on your behalf, potentially leading to misuse or unexpected costs. To reduce this risk, some platforms issue API key and secret pairs, where the secret is used to sign requests or is kept server-side, enabling stronger verification and more controlled access.

To Sum It Up

At the core, modern authentication is about proving who someone is and safely remembering that trust over time. It helps systems let the right people and programs in, without repeatedly sharing sensitive information. The goal is to make access feel simple for legitimate users, while remaining difficult to exploit if something goes wrong.

Everything should be made as simple as possible, but not simpler.

~Albert Einstein