Authentication Service Devlog 001 - The Think through.

This is a blog related to the development of the Authentication service. This is a new thing I am trying where in I am documenting my development journey and the thought processes involved while making this piece of software.

Let's start with the repo: https://github.com/Padmaj-Nikam/auth . Yeah feel free to fork it/clone it/appreciate it/email me if you want to collaborate.

This is an ever evolving project and my goal is to achieve agent authentication and rbac for multi-agentic systems.

Before moving forward, you guys need to know that an Authentication service is a foundational service to any modern application, it can be a standalone service in your cluster or part of a monolith. Regardless it is going to perform these two functions:

• Authentication - This functionality answers the "Who is this?" question to the system. Creating a new record in the database during signup or verifying an existing record during signin.
• Authorization - This functionality deals with enforcing boundaries for different users by answering "What all is this entity allowed to do?" to the system. Hint: Super Admin | Content Admin | Member etc.

Tech Stack

Let me introduce you all to the amazing tech stack I will be working with to create this service, please note that this service is made to be deployed as a k8s workload using GitOps as the deployment strategy, but this series of devlogs will only contain details of the service side GitOps CI workflow configuration.

• Written in Go.
• API Framework used to create REST APIis Gin. Could have gone with chi, but some other time :)
• Since I am optimizing this service for millions of users, for now I have went with MongoDB as the primary database.
• Postman and Go testing package for API testing.
• Containerization is done via Docker and deployment is handled via GitHub Actions, ArgoCD on Kubernetes.

At this point in time these will be the only technologies we will be working with. I plan to implement observability for distributed tracing later on, but my core focus will be to get the core functionality right.

Before moving towards the present implementation, let's take a step back and understand the landscape of authentication systems. One of the biggest misconceptions I had when I first started backend engineering was that authentication simply meant email + password. Turns out, that is just one very small piece of a much larger puzzle.

Depending on who or what is trying to prove its identity, the authentication mechanism changes. A human logging into an e-commerce website, a backend service talking to another backend service, and an AI agent trying to access your calendar are all authentication problems, but they are solved differently.

1. Basic Authentication

This is the oldest auth mechanism since internet started becoming popular. Here the client sends its username and password with every request using the Authorization header. The credentials are simply Base64 encoded(not encrypted), which means anyone intercepting the request can easily decode them if HTTPS isn't being used.

While extremely simple to implement, Basic Authentication has a few obvious drawbacks:

• The credentials are transmitted on every request.
• The server has to verify the password every single time the user requests something.
• Password rotation becomes difficult, meaning if you change the password then you will be required to update every client at the exact same time, leading to service downtime.
• It doesn't scale very well for modern applications.

You will still find it being used for Internal tools, legacy enterprise systems, quick API prototypes and dev envs but for internet-facing applications, there are much better alternatives and this becomes a big NO NO.

2. Session-Based Authentication

This is what most of us unknowingly used for years while browsing websites. Instead of sending your password with every request, the server creates a session after you log in and stores it somewhere (usually memory or Redis). The browser only stores a session identifier inside a cookie.

Advantages:

• Easy to revoke sessions.
• No sensitive information stored in the browser.
• Mature and battle-tested.

Disadvantages:

• The server now needs to maintain session state.
• Scaling horizontally requires a shared session store.

I am not using this approach cause "cloud is expensive" and I am poor as of now and a strong believer of client side token storage.

3. Token-Based Authentication (JWT)

This is what I use and most backend engineers work with in 2026. Instead of maintaining a session on the server, the server generates a signed token after successful authentication. This token acts like your library pass or metro card and is stored in your browser's session storage.

One interesting thing most real-world systems do is that the server does not issue just one token. It typically issues two tokens:

• Access Token (JSON Web Token)
• Refresh Token

Access Token (JSON Web Token)

This token is sent with every API request Authorization: Bearer <Access Token>. The receiving service verifies the signature often times using a middleware and trusts the claims inside the token without needing to call the authentication service.
This is why it is so powerful for microservices architectures.

But Why do you need the Refresh Token?

The reason is because Access Token is a short-lived token(It has to be by nature to be secure from token theft.), then the question comes "Won't the user be forced to log in again every 15 minutes?"

This is exactly what Refresh Tokens solve. A refresh token is a long-lived credential used only to obtain new access tokens. Think of it as an Aadhaar card required to get a metro card.

It is:

• Stored securely (usually HttpOnly cookies or secure storage)
• Not sent with every request
• Used only with the authentication server

How does the Refresh Token flow work in my Authentication service?

User logs in > Server issues: 1. Access Token (short-lived) & 2. Refresh Token (long-lived) > Client uses Access Token for API calls > Access Token expires > Client sends Refresh Token to Auth Server > Auth Server issues new Access Token

4. OAuth 2.0 (Open Authorization)

Now we enter the part that confused me for the longest time.

OAuth is not an authentication protocol.

Yes, you read that correctly.

OAuth is an authorization framework that allows one application to access another application's resources on behalf of a user without ever seeing their password.

Think about the "Continue with Google" button. Your application never receives your Google password.

Instead:

Google authenticates you. Google asks whether you want to grant access. Your application receives an authorization token.

That is OAuth. Authentication is actually provided by another protocol built on top of OAuth called OpenID Connect (OIDC), which we'll cover later in this series because understanding the distinction is incredibly important.

This is where we are folks! I am working on Google and GitHub OAuth implementation, post that I will be taking on API Key Authentication.

If you are curious about what REST API is and whether it is the best choice for your web application, checkout my earlier blog: REST vs gRPC: Why choosing the right one matters?