DEV Community: Guroosh

Beyond the Password: Modern Authentication Explained

Guroosh — Thu, 04 Jun 2026 10:28:59 +0000

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:

The user logs in using their username and password (credentials).
After successful authentication, the server generates two tokens: an access token and a refresh token.
The server returns both tokens to the browser.
The browser stores the access token and refresh token securely (often using different storage mechanisms for each).
The access token is sent with every authenticated request to prove the user’s identity.
When the access token expires, the client sends the refresh token to the server to request a new access token.
The server validates the refresh token and if valid, issues a new pair of access and refresh tokens.
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

Git: Best Practices for Professionals

Guroosh — Mon, 25 May 2026 14:16:10 +0000

Developers working in fast-moving teams often deal with overlapping work, long-running features, and reviews that depend on clear and reliable history.

This guide focuses on common Git problems developers face when working in teams and highlights the techniques that keep workflows stable, predictable, and easy to maintain.

Handling Merge Conflicts the Right Way

You created a Pull Request (PR) and when it’s time to merge it to main you are hit with a Merge Conflict on the UI. Here’s how to handle the conflict efficiently and seamlessly.

Note: Resolving the actual conflict will always be a manual task at the code level.

1. Check your status when on your feature branch

git status

2. Checkout to the main branch — the one your PR needs to be merged to

git checkout main

3. Then git pull to get latest main in your local

git pull

4. Switch back to the feature branch the PR is based on

git checkout feature-branch

5. Execute the Merge Command:

git merge main    # (this tries to merge the main branch to the feature branch)

After running the merge command you will get conflicts in certain files, these conflicts should replicate the original merge conflicts being faced in the Pull Request.

Now the conflicts need to be merged manually and can incur code loss, which is fine if both the main and feature branches are pushed in origin.

git status               
git add resolve files    # add all the files with resolved code
git commit               # just git commit; without the -m flag
git push -u origin HEAD

Running git commit will auto create a Merge Commit so you don’t need to provide any custom message.

After pushing to origin, the PR should not show any conflicts and the commit history in the feature branch should have a commit with an auto-merge message like this: Merged PR 123: Updated the UI with new design.

Reverting a Pushed Commit

Often at times we push and merge a commit to the main branch but then things go wrong and we end up introducing unexpected bugs into production code.

This is where you can safely revert the bad commit until the issue is identified. Here is how to do it safely:

1. Update your local repository

git checkout main
git pull

2. View the recent commits

git log

Here find the bad commit and copy the commit hash, which should look something like this: c41975d1dae1cc69b16ad8892b8c77164e84ca39.

3. Revert the individual commit

git revert c41975d1dae1cc69b16ad8892b8c77164e84ca39

git revert <commit-hash> automatically creates a commit message with a revert message:

Revert “Updated the UI with new design” This reverts commit c41975d1dae1cc69b16ad8892b8c77164e84ca39.

4. Verify and Push to main

git status
git push -u origin HEAD

Verify using git status that you are on the main branch and your local is a commit ahead of origin. git push to push the reverted code changes to origin.

Using stash the Right Way

Imagine you are working on a feature and have some useful changes on local but you have to pull the latest code from main to work on top of, so you do a git pull but end up getting the following message:

error: Your local changes to the following files would be overwritten by merge:
    <file names>
Please commit your changes or stash them before you merge.
Aborting

Here git already gives you a hint of what you need to do.

Using git stash the right way:

git stash
git pull
git stash apply    # this reapplies the latest stashed changes in your local

Note: this might give you merge conflicts.

This can be unsafe if you forget to reapply the changes immediately and lose track of the stashed code, so it is recommended for only small changes.

A safer approach for larger changes would be to ensure you checkout to a new branch and push your changes to origin. Which allows you to freely pull the latest code and merge it to your working branch without losing your code.

Note: this might also give you merge conflicts.

Resetting to a Previous Commit

What if you are working locally and have a few bad commits which you want to get rid of.

When can this happen:

You were resolving a merge conflict but end up with bad commits.
You have some unwanted commits in your local which you do not want or even remember — can happen if you restart work on an old feature after a long time.
Or you get the following message and git pull raises merge conflicts.

Your branch and 'origin/<branch>' have diverged,
and have 4 and 2 different commits each, respectively.
 (use "git pull" to merge the remote branch into yours)

If you are sure your local commits are unwanted or backed up, you can get rid of them by resetting your commit history by running the following command:

git reset --hard HEAD~

CAUTION: This command destroys your local commits permanently!

This resets the local HEAD to one previous commit.

If you have multiple local unwanted commits, you can run the command multiple times and sync cleanly using a git pull:

git reset --hard HEAD~
git reset --hard HEAD~
git reset --hard HEAD~
...
git pull

This will reset the HEAD multiple times to a stable commit and then you can sync with the origin with no issues.

Cherry Picking

Cherry-picking lets you take a specific commit from any branch and apply it onto another branch.

It is a useful command which lets you pick up all changes in a commit from one branch to another, given that the 2 parent branches have similar history.

Possible useful scenarios:

You fixed a bug on one branch e.g. “the dev branch”, and need the same fix to be applied on another branch e.g. “the release branch”.
You accidentally committed changes to a wrong branch and want to move the commit to the correct branch.

Here is how to cherry-pick a commit safely from branch A to branch B:

1. View the recent commits on branch A

git checkout branch-a
git log

Here find the commit to copy and copy its hash.

2. Switch to branch B

git checkout branch-b

3. Apply the individual commit

git cherry-pick c41975d1dae1cc69b16ad8892b8c77164e84ca39

On a successful cherry pick you will get the following message:

[main abc123] Fix login bug
 Date: Tue Dec 1 12:00:00 2020 +0200
 2 files changed, 10 insertions(+), 3 deletions(-)

After which it should be safe to push to origin.

Hope this guide helps.

Also, check out the guide Best Git Practices for Beginners if you haven’t already.

Git: Best Practices for Beginners

Guroosh — Mon, 25 May 2026 14:03:41 +0000

Git and GitHub are essential tools for software development, yet many beginners avoid using them properly due to concerns about making mistakes. They worry about accidentally deleting production code, pushing secrets, or exposing poorly written code. However, the real problems that emerge are less dramatic but far more damaging: messy commit histories, abandoned branches, and a lack of context.

This guide outlines simple, reliable practices that keep your workflow clean, predictable, and professional.

Essential Commands to Stay in Control

Git provides numerous commands to check your repository status, and running them causes no harm. In fact, you should develop a habit of using them frequently:

1. git status

The most important command, use it obsessively whenever you can.
Shows your current branch, what has changed, which files are added, and how your commits compare to the remote origin.

2. git pull

Generally safe to run at any time, especially before starting a new task.

3. git diff

Useful for reviewing your unstaged changes.

4. git log

Useful for reviewing the commit history in your local repository.

Starting with a new Feature

When beginning a new feature, first ensure everything is up to date:

git status     # Ensure you're on the main branch

If you’re not on the main branch, switch to it:

git checkout main

Then continue with:

git pull
# Output example:
# remote: Enumerating objects: 3, done.
# ...
# From github.com:repo/project
#    a3c912d..e71b4ac  main       -> origin/main
# Updating a3c912d..e71b4ac
# Fast-forward
#  README.md | 4 +++-
#  1 file changed, 3 insertions(+), 1 deletion(-)

git pull     # Run again to confirm
# Already up to date.

git log      # Optional, to check the latest commits in your local history

git checkout -b a-new-branch-with-a-unique-name  # -b to create a new branch

git status   # Confirm you're on the new branch

You’re now ready to start coding.

Name your Branches Clearly

Avoid generic names like refactoring, ui_update, or bug_fix.

Branch names should aim to be:

Informative: Clearly communicate the purpose
Unique: Prevent accidental conflicts with existing branches

A few good examples of branch names:

fixing-bug-payment-timeout-using-redis
feature/add-user-profile-with-updated-fields
task-123--fix-db-connection-issue

If available, include the ticket/task number in the branch to ensure uniqueness and improve traceability.

Commit and Push Frequently to Your Branch

New developers hesitate to push code for various reasons:

the code isn’t working yet
they’re hiding unfinished work, or
they fear accidental merges.

However, pushing frequently to a feature branch is exactly what it’s designed for.

Here’s how to do it:

git status                                 # Ensure you're on the correct branch
git add app/config api/src README.md       # Add only the files you want
git status                                 # Verify what's staged (colored display)
git commit -m "A Good Commit Message"
git push -u origin HEAD

Tip: If you are on the correct branch git push -u origin HEAD will always work, no need to copy and paste the specific branch name.

After pushing, create a Pull Request (PR) immediately:

New developers assume a PR should only be created when the work is finished. This is incorrect. Opening a PR early provides several benefits:

A clear, visual summary of all ongoing changes
An easy way to track progress as you develop

PRs are not a sign of completion.

In fact, most major Git platforms (GitHub, Azure Repos, etc.) offer Draft PRs to prevent accidental merges and to signal that the work is still in progress.

Option to convert a PR to a Draft PR in Github

Option to Create a Draft PR in Azure DevOps

Avoid adding all files to the staging area

Blindly adding everything with git add . risks pushing:

OS-specific hidden files like .DS_Store
Temporary artifacts
Editor swap files

Instead, intentionally add specific files to the staging area:

git add app/config app/utils api/src README.md

However, as a long term solution .gitignore should be used to avoid staging any unwanted files or folders.

Even with a well-maintained .gitignore, make it a habit to add specific files deliberately rather than relying on git add ..

Closing and Merging the PR

Write Clear, Informative Commit Messages

When it’s time to close the PR, the final commit message must be clean and informative. Individual commit messages on the branch won’t appear in the main history, so focus on the PR’s merge message.

A Good Commit Message explains what changed and why. For example:

Bad: “UI changes”
Better: “Update to hide unused sidebar buttons to simplify UI”

Tip: Git platforms like GitHub auto-generate merge commit messages and automatically reference PRs using #<number>, which helps maintain a searchable history of closed PRs.

Squash and Merge for Cleaner History

When merging a pull request, use Squash and Merge.

Benefits of Squashing and Merging:

Your main branch history remains readable, each feature appears as a single commit.
Individual features are easier to revert if needed by just reverting a single squashed commit.
Developers can commit frequently on their branch without worrying about cluttering the main branch’s commit history.

Delete the Feature Branch After Merging

After a PR is merged:

Delete the feature branch immediately.

Tools like GitHub and Azure Repos retain the PR history, so nothing is lost.

GitHub lets you know that a branch can be safely deleted

Azure Repos recommeds to delete the source branch when merging a PR

Ideally, only the main branch and active work-in-progress branches should remain in the repository. This keeps the repository clean and prevents confusion by having abandoned branches.

Hope this guide helps.

If you’d like to explore more advanced Git concepts, workflows, and best practices, you can read my Guide for Professional Developers.