Fetching Google User Profiles with Access Tokens

Hello! Welcome back to our series on building a secure authentication system.

In our last lesson, we successfully completed the OAuth 2.0 authorization code flow by exchanging the temporary code for a set of tokens from Google, including the all-important access_token and id_token.

Today, we'll put those tokens to use. The goal for this lesson is to retrieve and validate the user's profile information from Google's APIs using the tokens we just obtained. This step is the bridge between authenticating a user with Google and identifying them within our own application. By the end of this lesson, you'll have the user's verified name, email, and unique Google ID, ready for the next stage.

1. From Token to Identity: Accessing User Data

The tokens you received from Google are credentials. The access_token is a key that grants permission to access specific Google APIs on behalf of the user, while the id_token is a verifiable assertion about the user's identity. The permissions and data you can access are defined by the scopes you requested in the initial authorization step (e.g., openid, profile, email).

There are two primary, standard-compliant methods for retrieving the user's profile information on the server side:

1. Using the access_token to call the userinfo endpoint.
2. Decoding and validating the id_token directly.

Let's explore these options to understand their mechanics and trade-offs.

As you've read, both methods are valid, but they serve slightly different purposes. Using the userinfo endpoint is a classic OAuth 2.0 pattern for fetching data from a resource server. Decoding the id_token is a core feature of OpenID Connect (OIDC), the identity layer built on top of OAuth 2.0, and is specifically designed for retrieving identity claims.

2. The userinfo Endpoint in Practice

Let's briefly look at how a raw API call to the userinfo endpoint would work. This helps in understanding what our libraries are abstracting away. The process involves making a GET request to a specific URL and including the access_token in the Authorization header.

The curl command you saw, curl -H "Authorization: Bearer <access_token>", is a standard way of interacting with protected APIs. While we could construct this fetch request manually, the google-auth-library we've already installed provides a more robust and idiomatic way to handle identity verification, which brings us to our implementation.

3. Implementation: Verifying the id_token

For our use case—securely identifying the user upon sign-in—the recommended approach is to verify and decode the id_token. The google-auth-library provides a verifyIdToken method that handles this perfectly.

This method is superior to simply decoding the token because it performs several critical security checks:

• Signature Verification: It cryptographically verifies that the token was signed by Google and has not been tampered with.
• Audience (aud) Check: It ensures the token was issued specifically for our application by checking if the aud claim matches our GOOGLE_CLIENT_ID.
• Issuer (iss) Check: It confirms the token was issued by Google.
• Expiry Check: It verifies that the token is not expired.

Let's update our callback handler to perform this verification.

Update the file: src/routes/api/auth/google/callback.ts

We will add the new logic inside the try...catch block from the previous lesson, right after we receive the tokens.

import {
  eventHandler,
  getQuery,
  getCookie,
  deleteCookie,
} from "vinxi/http";
import { oauth2Client } from "../../../../lib/google-auth";

export default eventHandler(async (event) => {
  // --- Part 1: Validation (from previous lesson) ---
  const query = getQuery(event);
  const storedState = getCookie(event, "oauth_state");

  if (!query.state || !storedState || query.state !== storedState) {
    event.node.res.statusCode = 400;
    return { error: "State mismatch" };
  }

  if (query.error) {
    event.node.res.statusCode = 401;
    return { error: query.error, description: query.error_description };
  }

  // --- Part 2: Token Exchange & Profile Retrieval ---

  const authCode = query.code as string;
  const storedCodeVerifier = getCookie(event, "pkce_code_verifier");

  if (!authCode || !storedCodeVerifier) {
    event.node.res.statusCode = 400;
    return { error: "Missing authorization code or PKCE verifier" };
  }

  const cookieOptions = {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    path: "/",
  };
  deleteCookie(event, "oauth_state", cookieOptions);
  deleteCookie(event, "pkce_code_verifier", cookieOptions);

  try {
    // 1. Exchange the authorization code for tokens
    const { tokens } = await oauth2Client.getToken({
      code: authCode,
      codeVerifier: storedCodeVerifier,
    });

    // Ensure the id_token exists
    if (!tokens.id_token) {
      event.node.res.statusCode = 500;
      return { error: "ID token not found in token response" };
    }

    // 2. Verify the ID token to get user profile information
    const ticket = await oauth2Client.verifyIdToken({
      idToken: tokens.id_token,
      audience: process.env.GOOGLE_CLIENT_ID, // Specify the CLIENT_ID of the app that accesses the backend
    });

    const payload = ticket.getPayload();

    if (!payload) {
      event.node.res.statusCode = 500;
      return { error: "Failed to get token payload" };
    }

    // 3. User information is now in the payload
    // The 'sub' field is Google's unique identifier for the user.
    const userProfile = {
      googleId: payload.sub,
      email: payload.email,
      name: payload.name,
      picture: payload.picture,
    };

    // For now, we'll return the profile to confirm success.
    // In the next lesson, we'll use this to create a local user and a JWT.
    return {
      message: "Authentication successful! User profile retrieved.",
      user: userProfile,
    };

  } catch (error: any) {
    console.error("Authentication process failed:", error.response?.data || error.message);
    event.node.res.statusCode = 500;
    return { error: "Failed during authentication process." };
  }
});

Code Breakdown:

1. Get Tokens: We still call oauth2Client.getToken() as we did in the last lesson.
2. Verify ID Token: This is the new, crucial step. We pass the id_token from the tokens object to oauth2Client.verifyIdToken(). We also provide our GOOGLE_CLIENT_ID as the audience to ensure the token was intended for our application.
3. Get Payload: If verification is successful, ticket.getPayload() returns a JSON object containing the user's identity claims. This payload is now considered trustworthy.
4. Extract Profile: We extract the key fields we need: sub (the unique subject/user ID), email, name, and picture. We map them to a userProfile object for clarity.
5. Return Profile: We return this userProfile object in the response. If you test the flow now, you should see your own Google profile information returned as JSON in the browser.

Conclusion

Excellent work! You have now connected the dots from a user clicking "Sign in with Google" to having their verified, trustworthy identity information available on your server.

Key Takeaways:

• There are two main ways to get user info: calling the userinfo endpoint with an access_token or decoding the id_token.
• For authenticating a user (the "who"), the OpenID Connect pattern of verifying the id_token is the most direct and secure method.
• The google-auth-library's verifyIdToken method is a powerful tool that performs essential security validations, such as checking the signature, audience, issuer, and expiration.
• A successful verification yields a payload containing the user's unique ID (sub), email, name, and other profile details permitted by the requested scopes.

Next Lesson Preview:
With the user's Google profile in hand, what's next? We need to integrate this identity into our own application's authentication system. In the next lesson, we will map the OAuth identity to an application-specific JWT. This involves looking up the user in our database by their Google ID, creating a new user record if one doesn't exist, and then issuing our own JWT to manage their session going forward.