OAuth 2.0 / OpenID Connect : Understand in 3 Minutes

#oauth20 #openidconnect #secureauthentication #abotwrotethis

Problem Statement

OAuth 2.0 and OpenID Connect (OIDC) are the industry standards for managing secure user authorization and authentication, respectively, often seen together as a single "login with X" solution. You encounter them every time your app needs to let users sign in with Google, let a third-party tool access their GitHub repos, or when your microservices need to securely communicate. If you've ever wondered, "How do I securely let another app access my user's data without giving them the password?" or "How do I know who the user actually is after they login?"—you’ve hit the exact problem these protocols solve.

Core Explanation

Think of OAuth 2.0 as a secure valet key. When you use "Sign in with Google," your app (the Client) doesn't get the user's password. Instead, it gets a special, limited-use token (the valet key) from Google (the Authorization Server). This token grants your app specific, pre-approved permissions (scopes) to access the user's data (like their email) from Google's Resource Server.

OpenID Connect is a thin identity layer built on top of OAuth 2.0. If OAuth is about access (what can you do?), OIDC is about identity (who are you?). It standardizes how to get basic profile information about the user, like a username or email, packaged in a secure token called an ID Token.

Here’s how they work together in a typical flow:

User Initiates: Your user clicks "Login with Google."
Redirect & Consent: Your app redirects the user to Google. Google asks, "App X wants your email and profile. Allow?"
Authorization Grant: The user agrees, and Google sends a one-time authorization code back to your app.
Token Exchange: Your app securely exchanges this code with Google for two tokens: an Access Token (OAuth 2.0, for accessing APIs) and an ID Token (OIDC, a JWT containing verified user info).
Use Tokens: Your app can now verify the user's identity using the ID Token and call Google APIs on their behalf using the Access Token.

Practical Context

Use OAuth 2.0 when your application needs delegated access to a user's resources or data hosted by another service (like posting to a user's Twitter feed or reading their Google Calendar). Use OpenID Connect specifically when you need to verify a user's identity for login. They are almost always used together for social login.

When not to use it: If you are building a simple, self-contained application where users directly create accounts with you (using a username/password you store), traditional session-based authentication is simpler. Don't over-engineer by adding OAuth/OIDC to an internal tool that only uses a company directory.

You should care because:

Security: It’s far safer than handling passwords yourself and is the accepted best practice.
User Experience: Reduces sign-up friction ("one-click login").
Interoperability: It’s the universal language for API access and federated identity.

Quick Example

Here’s a simplified snippet showing the server-side code that might handle the callback from Google after a user clicks "Login":

// Your server receives the authorization code from Google
app.get('/auth/google/callback', async (req, res) => {
  const { code } = req.query;

  // 1. Exchange code for tokens
  const tokenResponse = await exchangeCodeForTokens(code);

  // 2. OIDC: Verify and decode the ID Token to get user info
  const userInfo = decodeAndVerifyIdToken(tokenResponse.id_token);
  console.log(`User ${userInfo.email} is authenticated.`);

  // 3. OAuth 2.0: Use the Access Token to call an API
  const calendarEvents = await fetchGoogleCalendarEvents(tokenResponse.access_token);

  // 4. Create a session for the user in your app
  req.session.userId = userInfo.sub;
  res.redirect('/dashboard');
});

This example shows the separation of concerns: the ID token tells you who logged in, and the access token lets you perform actions for them.

Key Takeaway

Remember this: OAuth 2.0 is for authorization (access to data), OpenID Connect is for authentication (verifying identity). Together, they let you implement secure, standardized "log in with X" features without managing passwords. For a hands-on, definitive guide, bookmark the OAuth 2.0 Simplified website.

DEV Community