Angular8+Spring Boot集成Google社交登录的技术疑问咨询

Hey there! Let’s walk through each of your Google Sign-In questions with practical, stack-specific advice—since I’ve worked with similar Angular + Spring Boot setups before, I’ll share what’s worked for me:

1. How to get the user’s phone number from Google Sign-In? #

Google doesn’t return the phone number by default—you’ll need to request the additional scope https://www.googleapis.com/auth/userinfo.phone during the sign-in flow. Here’s what to do:

• Update your GAPI sign-in configuration to include this scope alongside email, profile, openid.
• Note that users will see a permission prompt asking to share their phone number, so you need to handle cases where they decline.
• Once authorized, you can fetch the phone number via the Google People API using the access_token you receive, or check if it’s included in the id_token payload (though calling the People API is more reliable, as the payload doesn’t guarantee this field).

2. Correct way to redirect to dashboard/welcome page after Google auth success? #

For Angular SPAs, avoid full-page refreshes—use the Angular Router for a smooth experience:

• After successfully retrieving the Google tokens (id_token/access_token) in your Angular component, first complete any necessary backend validation (like sending the id_token to Spring Boot to get your app’s JWT).
• Once you have your app’s auth token (or confirmed the user is valid), use the Router service to navigate:

  import { Router } from '@angular/router';
  
  // In your component method after auth success
  this.router.navigate(['/dashboard']);
  

• Make sure your dashboard route is protected by an Angular guard that checks for a valid auth token, so unauthenticated users can’t access it directly.

3. Should I use GAPI-provided tokens or generate my own JWT? #

Always generate your own JWT for your application. Here’s why:

• Google’s access_token is designed to access Google APIs (like People, Drive), not to authenticate users against your backend—it has a short expiry (1 hour) and doesn’t include custom claims your app might need (like user roles, internal PostgreSQL IDs).
• Your custom JWT lets you control expiry times, add app-specific data, and manage sessions independently of Google’s token lifecycle.
• Recommended flow: Frontend sends Google’s id_token to Spring Boot → Backend validates the id_token → Backend generates and returns your app’s JWT → Frontend uses this JWT for all subsequent API calls.

4. Do I need to re-verify the Google token in Spring Boot backend? #

Absolutely—this is non-negotiable for security.

• Frontend tokens can be tampered with or forged, so your backend must independently verify the id_token’s authenticity.
• In Spring Boot, you can use the Google Java Client Library to verify the id_token:

  import com.google.api.client.googleapis.auth.oauth2.GoogleIdToken;
  import com.google.api.client.googleapis.auth.oauth2.GoogleIdTokenVerifier;
  import com.google.api.client.http.javanet.NetHttpTransport;
  import com.google.api.client.json.gson.GsonFactory;
  import java.util.Collections;
  
  // In your auth service
  GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(new NetHttpTransport(), new GsonFactory())
      .setAudience(Collections.singletonList("YOUR_GOOGLE_CLIENT_ID"))
      .build();
  
  GoogleIdToken idToken = verifier.verify(googleIdTokenString);
  if (idToken != null) {
    GoogleIdToken.Payload payload = idToken.getPayload();
    String userId = payload.getSubject(); // Unique Google user ID
    String email = payload.getEmail();
    // Proceed to create user in PostgreSQL or fetch existing user
  } else {
    // Invalid token—reject the request
  }
  

• Verify key claims: issuer (accounts.google.com), audience (your client ID), expiry, and signature.

5. Best practices for handling sessions/state in social login? #

Stick to these guidelines for secure, user-friendly session management:

• Use HttpOnly, Secure Cookies for refresh tokens: Store your app’s refresh token in an HttpOnly cookie (inaccessible to frontend JS, mitigating XSS risks) and mark it as Secure (only sent over HTTPS).
• Short-lived JWTs: Set your app’s JWT expiry to 15–60 minutes. Use the refresh token to get a new JWT without requiring the user to re-login.
• Angular Interceptor: Create an HTTP interceptor to automatically attach the JWT to every API request via the Authorization: Bearer <token> header.
• Handle token expiry: Catch 401 Unauthorized responses in your interceptor, trigger a refresh token request, and retry the original request if successful. If refresh fails, redirect to the login page.
• Stateless backend: Since JWTs are self-contained, your Spring Boot backend doesn’t need to store session data—ideal for microservices.

6. Should I verify id_token or access_token in Spring Boot/microservices? #

Verify the id_token, not the access_token. Here’s the difference:

• id_token: A signed JSON Web Token containing user identity information (sub, email, name) meant for authentication. You can verify its signature directly against Google’s public keys, no need to call Google’s API.
• access_token: A bearer token for accessing Google APIs—it doesn’t contain user identity details, and verifying it requires calling Google’s token info endpoint (adding latency).
• The id_token is the correct choice for confirming the user’s identity before issuing your app’s own token.

7. How to maintain login state for users who previously logged in via Google? #

Use a combination of refresh tokens and auto-login checks:

• Refresh tokens: When a user logs in successfully, return a long-lived refresh token (e.g., 7–30 days) in an HttpOnly cookie. On subsequent visits, your Angular app can check if the refresh cookie exists, then call a backend endpoint to exchange it for a new JWT.
• Auto-login on page load: Add a guard or initializer in Angular that runs on app startup. It checks if a valid JWT exists in localStorage (or if the refresh cookie is present) and automatically navigates to the dashboard if authenticated.
• Remember me option: If you offer a “Remember me” checkbox, extend the refresh token’s expiry. But ensure refresh tokens are revocable (store them in PostgreSQL with a user ID, so you can invalidate them if the user logs out or changes their password).

内容的提问来源于stack exchange，提问作者arjun kumar