FastAPI Google OAuth认证后Cookie未在前端显示问题及安全传递Token方案咨询

Hey there! Let's tackle your problem head-on. First, let's figure out why your cookie isn't showing up in the browser, then go over some other secure ways to get that token to your frontend.

一、为什么Cookie没出现在前端？ #

Looking at your /google/callback code, the biggest issue is how you're handling the response: you're setting the cookie on the response parameter injected by FastAPI, but then you return a brand new RedirectResponse instance. The cookie you added to the original response never makes it to the browser because you're not using that object for the final redirect. That's the root cause!

A couple other things to check too:

• CORS Configuration: If your frontend is running on http://localhost:5173 and your backend is on a different port (like 8000), you need to enable CORS in FastAPI with credentials=True—browsers block cookies across origins unless explicitly allowed.
• Cookie Attributes: You set domain='localhost' which works for cross-port local development, but adding path='/' ensures the cookie is accessible across all paths of your frontend. Also, since you're using HTTP locally, don't set secure=True (you already have this right, just a reminder for production!).

Fix for the Cookie Issue #

Instead of setting the cookie on the injected response, add it directly to the RedirectResponse you're returning. Here's how to adjust your code in each branch:

# Create the redirect response first
redirect_response = RedirectResponse(url="http://localhost:5173/auth-success", headers=headers, status_code=302)
# Attach the cookie to this redirect response
redirect_response.set_cookie(
    key="access_token", 
    value=access_token, 
    httponly=True,
    domain='localhost',
    path='/',  # Ensures cookie works across all frontend paths
    same_site='lax'  # Helps prevent CSRF attacks
)
return redirect_response

This way, the cookie is included in the final redirect response, and the browser will store it properly.

二、其他安全传递Token到前端的方案 #

HttpOnly cookies are actually one of the safest options (they block XSS attacks from stealing tokens), but here are a few other secure approaches depending on your app's needs:

1. Session-Based Authentication #

Store the access token (or a unique session ID that maps to the token) in a server-side store like Redis or your database. Send the session ID as an HttpOnly cookie to the frontend. On every request, the browser sends the cookie, and your backend looks up the corresponding token to validate the user. This keeps the token off the frontend entirely, reducing exposure risk.

2. Short-Lived Access Token + Refresh Token (HttpOnly Cookie) #

• Send a short-lived access token (5-15 minutes) to the frontend, storing it only in memory (like Vue Pinia/React Context—never use localStorage/sessionStorage, as they're vulnerable to XSS).
• Store a long-lived refresh token in an HttpOnly cookie. When the access token expires, the frontend calls a refresh endpoint, and your backend uses the refresh token to issue a new access token. This limits damage if an access token is stolen, since it's only valid for a short time.

3. In-Memory Token Storage (No Persistence) #

For single-page apps (SPAs), keep the access token in the app's memory instead of any persistent storage. When the user refreshes the page, they'll need to re-authenticate (or you can use the refresh token in the HttpOnly cookie to silently get a new access token in the background). This avoids exposing the token to XSS attacks that target local storage.

关键安全提醒 #

• Use HTTPS in Production: Always serve your app over HTTPS—this encrypts token/cookie transmission and prevents eavesdropping.
• Restrict CORS Origins: Never allow * as an allowed origin. Only list your frontend's exact domain to prevent malicious sites from exploiting CORS.
• Set Proper Cookie Flags: In production, set secure=True (so cookies only send over HTTPS) and same_site='strict' or 'lax' to mitigate CSRF risks.

备注：内容来源于stack exchange，提问作者Mirzonabot Mirzonabotov