DEV Community

Cover image for Interview Question about Authentication: JWT vs OAuth2 vs SSO
Pau Dang
Pau Dang

Posted on • Edited on

Interview Question about Authentication: JWT vs OAuth2 vs SSO

#backend #authentication #security #architecture

Hello everyone! 👋

If you are preparing for a Backend, Fullstack, or Software Architecture interview, you will almost certainly encounter this "classic" question:

"Can you explain the difference between **JWT, OAuth 2.0 / Auth0, and **SSO? When should we use which?"

This is a fantastic question because it doesn't just test your networking theory; it evaluates your overall System Design mindset and application security knowledge. However, many developers often get confused and mistakenly treat all three of these concepts as interchangeable authentication methods.

In this article, let's dissect their true nature, how they work, their real-world use cases, and give you a killer comparison table so you can confidently ace this question in your next interview! 🚀

1. JWT (JSON Web Token) - "The Boarding Pass"

📌 Core Concept

JWT is not an authentication protocol or a login flow. It is purely a standardized token string format (RFC 7519) used for securely transmitting information between a Client and a Server.

Its structure consists of 3 parts separated by dots .:
Header.Payload.Signature

⚙️ How It Works:

  1. Login: User submits username/password to the Server.
  2. Token Creation: The Server validates the credentials -> Uses a Secret Key to digitally sign a JWT containing quick claims (e.g., user_id, role).
  3. Return to Client: The Server sends the JWT to the Client (which usually stores it in LocalStorage or an HttpOnly Cookie).
  4. Usage: For every subsequent request, the Client attaches the JWT to the Authorization Header (as a Bearer Token).
  5. Verification: The Server receives the request and, WITHOUT QUERYING THE DATABASE, simply verifies the digital Signature using its Secret Key to ensure the token hasn't been tampered with or expired.

🎯 When To Use It?

  • RESTful APIs and Single Page Applications (React, Vue, Angular).
  • Microservices Architecture: Internal services can "trust" each other and independently verify tokens without a central authority by sharing the Secret/Public Key.
  • When you need a Stateless security mechanism: It saves the Server's memory (RAM/Redis) since it no longer needs to track Session IDs for millions of active users.

2. OAuth 2.0 & Auth0 - "The Neighbor's Keys"

📌 Core Concept

This is the most frequently misunderstood group.

  • OAuth 2.0: This is an Authorization Protocol Framework. It was designed to allow Application A (e.g., a job board) to access your data on Application B (e.g., LinkedIn) WITHOUT you having to give Application A your password. When combined with OpenID Connect (OIDC), it acts as an Authentication layer.
  • Auth0 / AWS Cognito / Firebase: These are third-party Identity-As-A-Service (IDaaS) providers built on top of OAuth2/OIDC. You pay them to act as your "security guard." You no longer hash or store user passwords in your own database.

⚙️ How It Works (Example: "Login with Google"):

  1. User clicks "Login with Google". Your app immediately Redirects the user to Google's login page.
  2. The user enters their password on the google.com domain. (Your app remains completely blind to this password).
  3. Upon success, Google redirects the user back to your app, attaching a temporary code (Authorization Code).
  4. Your Server intercepts this Code and makes a back-channel API call to Google servers to exchange it for an Access Token (often formatted as a JWT) and an ID Token.
  5. Transaction complete, your Server issues a session to the User to access the system.

🎯 When To Use It?

  • Social Login: When your system requires "Login via Google / Facebook / GitHub".
  • Maximum Security, Zero Hassle: For large projects where you don't want the burden of managing password hashing, encryption, "forgot password" flows, MFA, etc., and prefer to Outsource/Delegate it entirely to a professional third-party IDaaS.

3. SSO (Single Sign-On) - "The Master Key"

📌 Core Concept

SSO is not a specific technology or library. It is a System Architecture / User Experience (UX) Pattern.

It allows a user to log in ONLY ONCE and seamlessly navigate across Multiple Independent Applications within the same ecosystem without ever having to log in again.
(Real-world example: You log into Gmail, then open YouTube or Google Drive — you are automatically logged in).

⚙️ How It Works:

SSO is usually implemented under the hood by IT using protocols like SAML 2.0 or OAuth2.0/OIDC.
There are 3 entities involved: App A, App B, and the Identity Provider (IdP - Central Auth Server).

  1. Access App A: Not logged in -> Redirected to the IdP.
  2. Login at IdP: Successfully enter user/pass -> IdP stores a shared Session Cookie on the browser -> Redirects back to App A with a token to activate App A.
  3. Access App B: Not logged in -> Redirected to the IdP.
  4. AUTOMATIC LOGIN: Because the IdP previously saved a Cookie on your browser -> It instantly recognizes you -> Skips the password prompt entirely -> Immediately redirects you back to App B with a Token. (You just see a quick screen flicker, and you're inside App B).

🎯 When To Use It?

  • Corporate/Enterprise Environments: A company has an HR system, Jira, and internal tools. Employees log into the company's central server once in the morning to use all three seamlessly. (Usually powered by Microsoft Entra ID or Okta).
  • Massive product ecosystems spanning multiple sub-domains (like Google or Atlassian).

💡 The "Checkmate": Interview Comparison Matrix

The secret to making interviewers nod in approval is pointing out the difference in Layers/Categories of these 3 concepts. They don't run parallel; they complement each other.

Criteria JWT OAuth 2.0 / Auth0 SSO
Core Nature A token string Format. An Authorization Protocol Framework / Service. A System Architecture / UX Experience.
Primary Goal Packaging and transmitting data (claims) securely between Client and Server. Delegating authentication/authorization to a 3rd party. Sharing a login session across numerous independent systems.
Interconnection Usually acts as the Access Token generated at the final step of an OAuth2 or SSO flow. Often utilizes JWTs to format the returned tokens. It can natively serve as the backbone to build an SSO system. SSO requires an underlying Identity Provider (IdP) server, which usually runs on SAML or OAuth 2.0 (and returns JWTs).
State Storage? Stateless (Server stores nothing). Can be Stateful or Stateless depending on implementation. Stateful (The central IdP MUST remember the user's Cookie session to auto-login App B).
Dependency Your backend code manages and signs the token directly. Relies on the infrastructure of an external provider (Google, Auth0...). Requires setting up and maintaining a centralized Identity Server (IdP) as the gatekeeper.

"Well, these 3 concepts frequently appear together, but they operate at entirely different layers. **SSO* is a user experience architecture (log in once, use everywhere). To actually build SSO, we need the capabilities of delegation protocols like OAuth2 / OIDC (Auth0 is a famous vendor in this space). And once that protocol flow finishes, the resulting session grant sent back to the client is usually packaged securely using the JWT string format."*

I hope this clears up the confusion and gives you a confidence boost for your upcoming Backend interviews! Let me know your thoughts or questions in the comments below.

If you are interested in a clean, highly optimized Node.js project structure supporting both MVC and Clean Architecture out of the box (with auto-generated Swagger docs!), check out my open-source CLI tool: *nodejs-quickstart-structure*** 🚀

Top comments (0)