Phase 3: Backend & APIs

OAuth 2.0, social logins & OpenID Connect

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you love reading and have hundreds of books at the huge City Main Library. You also found a cool new "Cool Book Reviews" website that helps you keep track of books you’ve read and want to read. This website needs to know some of your reading history or your list of favorite books from the City Main Library to work best.

Before, the only way for the "Cool Book Reviews" website to know your reading history was if you gave them your main library card number and secret PIN – that's like giving away your house keys! That’s risky because then they could borrow any book, change your address, or do anything you can do at the main library. Instead, the City Main Library has a clever system. When you click "Connect with City Main Library" on the "Cool Book Reviews" website, the main library asks you: "Hey, the Cool Book Reviews website wants to see your favorite books list. Is that okay?" If you say yes, the main library gives the Cool Book Reviews website a special, limited-access pass. This pass only lets them see your favorite books, and nothing else. It's like giving them a special visitor's pass that only opens the "favorite books" shelf, not the whole library. You never give your main library card number to the review site.

This special pass system is exactly how "Sign in with Google" or "Login with Facebook" works on many websites. When you click one of those buttons, that website is asking Google or Facebook for a special pass to know just enough about you (like your name and email) so you can log in easily, without making a brand new account and remembering another password. It’s like using your main library card to say "Yep, I'm a real person" for the review website, without actually giving them your card. This makes logging in super quick and safe, because you're not typing your Google password into every new website you visit.

So, when you're building your own cool websites or apps, you can use this "special pass" system to let people log in easily and securely. You can allow them to use their existing accounts from places like Google or Facebook, saving them the hassle of creating new usernames and passwords for your app. This means your users have an easier, safer time using your creations!

As a Full-Stack Developer, understanding OAuth 2.0, social logins, and OpenID Connect is crucial for implementing secure and user-friendly authentication and authorization flows. At its core, OAuth 2.0 is an authorization framework, not an authentication one. It enables a third-party application (your app, the "Client") to obtain limited access to a user's resources (e.g., their photos on Google Photos, their repos on GitHub) hosted by another service (the "Resource Server"), without the user ever sharing their credentials with your app. Think of it as granting a valet (your app) permission to park your car (access resources) without giving them your house keys (your password). It defines various "flows" (like the Authorization Code flow) for how this access is granted and tokens (like access tokens) are exchanged.

Social logins are a direct, practical application of OAuth 2.0. When a user clicks "Sign in with Google" or "Login with Facebook" on your website, your application initiates an OAuth 2.0 flow with the respective social provider. This provides a convenient way for users to log in without creating new accounts and memorizing more passwords. However, raw OAuth 2.0 primarily tells your application that a user has granted access to certain resources, not who that user definitively is. While you might get an email or name as part of the authorized access, there's no inherent mechanism in OAuth 2.0 itself to verify the user's identity securely across different providers.

This is where OpenID Connect (OIDC) steps in. OIDC is an identity layer built on top of OAuth 2.0, specifically designed for user authentication. It provides a standard way for clients to verify the identity of an end-user based on the authentication performed by an Authorization Server (like Google or Facebook) and to obtain basic profile information about that user. The key addition is the ID Token, a JSON Web Token (JWT) that contains verifiable claims about the authenticated user (e.g., their user ID, name, email). This ID Token is cryptographically signed, allowing your application to trust the identity information it contains. So, for "Sign in with Google," your app uses OIDC (which leverages OAuth 2.0 for the underlying authorization exchange) to not just get an access token, but also a verified ID Token proving who the user is.

Key Takeaways

  • OAuth 2.0 is an authorization framework for delegated access to resources, not user authentication.
  • Social logins (e.g., "Sign in with Google") commonly use OAuth 2.0 for user convenience.
  • OpenID Connect (OIDC) builds on OAuth 2.0, adding an identity layer for user authentication.
  • OIDC provides an ID Token (a signed JWT) which contains verifiable information about the logged-in user.

Code Example

Preview

How this code works

This code snippet enables a "Sign in with Google" button on a webpage. When clicked, it initiates the first step of the OAuth 2.0 Authorization Code Flow, redirecting the user's browser to Google's authentication service. This process allows the application to securely verify the user's identity and obtain permission to access basic profile information, like their name and email, without ever handling their Google password directly. The HTML <button> element triggers the initiateGoogleLogin() JavaScript function, which contains all the logic for this initial redirect.

Inside initiateGoogleLogin(), the code constructs a special URL for Google. It starts with Google's authUrl, then appends several params (parameters) using URLSearchParams. Key parameters include client_id, which identifies the application, and redirect_uri, specifying where Google should send the user back after login. The response_type: 'code' parameter requests a temporary authorization code. The scope parameter (openid profile email) asks for basic identity, profile, and email data. A subtle but important parameter is access_type: 'offline', which, contrary to implying no internet, allows the application to obtain a refresh token. This token enables the application to get new access tokens later without requiring the user to re-authenticate, facilitating persistent sessions. Finally, window.location.href redirects the user's browser to this carefully crafted Google URL.

Resources

Related Articles

Hand-picked reads to go deeper on authentication & authorization.

Back to Full-Stack Developer Roadmap