Authentication Explained: When to Use Basic, Bearer, OAuth2, JWT & SSO
Authentication Explained: When to Use Basic, Bearer, OAuth2, JWT & SSO
Preparing for System Design Interviews? Join ByteByteGo now for a structured preparation. They are also offering a rare 50% discount now on their lifetime plan.
Hello guys, when you design any modern distributed system, one of the earliest, and most critical questions is: How do users and services prove who they are?
Authentication isn’t just a security checkbox; it shapes your system’s scalability, user experience, latency, caching strategy, and even how microservices talk to each other.
In system design interviews, candidates often jump straight into databases, load balancers, and microservices but overlook how authentication fits into the overall architecture.
A solid understanding of authentication models helps you design systems that are secure and practical to operate at scale.
In this guide
, Senior Software engineer, System Design expert, YouTuber and instructor of popular System Design course - System Design for Beginners: Build Scalable Backend Systems on Udemy, breaks down the core building blocks of authentication — Basic Auth, Bearer Tokens, OAuth2, JWT, and SSO and explains when and why you’d use each in a real-world system design scenario.By the end, you’ll understand how these mechanisms work, the trade-offs involved, and how to select the right approach for large, distributed applications.
By the way, If you’re preparing for System Design Interviews or want to move from being a developer to thinking like an architect, mastering these concepts is essential. I highly recommend ByteByteGo — one of the best platforms that explains these distributed system patterns visually and intuitively.
Their diagrams and case studies (like how browsers fetch content, how CDNs reduce latency, and how DNS propagation works) make complex concepts easy to grasp.
ByteByteGo is currently offering up to 50% OFF on their annual plan — a perfect time to start your system design learning journey.
With that, over to Hayk to take you through the rest of the article.
Before a system can authorize or restrict anything, it needs to know the identity of the requester.
That’s what authentication does — it verifies that the person or system trying to access your app is legit.
In this post, you’ll learn how modern apps handle authentication, from basic tokens to OAuth flows and Single Sign-On.
What is Authentication?
Authentication is the first gate.
Before you can access data or perform actions, the system needs to know who you are.
Once identity is confirmed, then the system can move on to what you’re allowed to do — that’s authorization, which we’ll cover in the next lesson.
Basic Authentication
Basic Authentication is the oldest method, username and password are encoded and sent with every request.
It’s simple, but insecure unless wrapped in HTTPS. That’s why it’s almost never used in production anymore.
Bearer Tokens
Bearer tokens are more secure. Instead of a password, you send a token with each request.
The server checks the token and, if valid, grants access.
This is the standard approach in API design today. It’s fast, stateless, and because of that, it’s easy to scale.
OAuth2 and JWTs
OAuth2 is a protocol that lets users log in through a trusted provider — like Google or GitHub — without sharing passwords with your app.
The provider gives you an access token, usually in the form of a JWT, which is a signed object that contains user info.
JWTs are also stateless, which means you don’t need to store sessions. The server just verifies the token and reads the data inside.
Want to See This in Real Projects?
If you want to see how these authentication flows are implemented in real-world projects — not just in theory — check out my mentorship program.
Access and Refresh Tokens
Modern systems use short-lived access tokens for API calls and long-lived refresh tokens to stay logged in.
When the access token expires, the refresh token quietly gets a new one behind the scenes.
This way, users don’t have to log in again, and your system stays secure.
Single Sign-On (SSO) and Identity Protocols
SSO lets users log in once and access multiple services.
Behind the scenes, it’s powered by identity protocols like OAuth2 and SAML.
OAuth2 is used in most modern apps, like “Login with Google.”
SAML is older and XML-based, but still common in companies that use things like Salesforce or internal dashboards.
These are identity protocols, meaning they define how apps securely exchange user login info.
Authorization is Next
You now know how apps verify identity using tokens, OAuth2, JWTs, and SSO. These are the same tools used by the systems you use every day — and they form the backbone of secure, scalable systems.
Authentication tells us who the user is…
But that’s not enough.
We still need to decide what they’re allowed to do — and that’s Authorization, which we’ll cover in the next post.
If you like this article then I highly recommend you to subscribe to Hayk’s newsletter and his YouTube channel
Other System Design Articles you may like
 | A guest post by
|
Nice breakdown. Funny how auth feels “basic” on paper but ends up shaping half your system in real life 😅
Solid refresher, thanks!
Excellent breakdown of when stateless JWT architectrure makes sense versus session-based approaches. The access/refresh token pattern you describe solves a real problem: most systems need the horizontal scalability of stateless tokens but can't tolerate the security risk of long-lived access tokens. What's less obvous is the token revocation challenge with JWTs. Once issued, they're valid until expiry even if you need to immediately revoke access. Some teams maintian revocation lists, which reintroduces statefulness, while others accept the risk window between revocation events and token expiry.