跨独立域名Cookie操作及个人CDN的Cookie认证授权咨询

Great question—handling cross-domain auth for independent domains with a shared personal CDN is a common but tricky scenario. Let’s break this down step by step, covering both the auth flow and the cookie configuration details you need.

Since your three apps (Application1.com, Application2.com, WebSite1.com) and your CDN (personalCDN.com) are all independent domains, browser same-origin policy blocks direct cookie sharing. The fix is a token-based redirect flow to sync auth status between apps and the CDN, paired with careful cookie configuration on the CDN side.

Browsers enforce the same-origin policy: cookies set for one independent domain can’t be accessed by another. So you can’t just set a cookie on Application1.com and expect personalCDN.com to read it. Instead, we’ll use a short-lived, one-time auth token to pass verified user identity from the app to the CDN, then let the CDN set its own cookie for future requests.

2.1 Unified Login Flow (Any App Domain) #

• When a user logs into any of your three apps (e.g., Application1.com), your app’s backend verifies their credentials and generates a short-lived, one-time auth token (could be a signed JWT or cryptographically random string, valid for 5-10 seconds max).
• Your app redirects the user to a dedicated auth callback endpoint on your CDN, like:

  https://www.personalCDN.com/auth/callback?token=YOUR_ONE_TIME_TOKEN&redirect=https://www.Application1.com/after-login
  

  Include the original app’s redirect URL so you can send the user back after setting the CDN cookie.

2.2 CDN Cookie Setup Logic #

When your CDN receives the callback request:

1. Validate the one-time token: Either call your app’s backend to confirm the token is valid, or if using a signed JWT, verify the signature directly on the CDN (if it supports custom code/edge functions).
2. If validation passes, set an auth cookie for personalCDN.com with these critical attributes:
   • Domain=personalCDN.com: Ensures the cookie is only sent to your CDN, not other domains.
   • Secure=true: Forces the cookie to only be sent over HTTPS (matches your setup).
   • HttpOnly=true: Blocks frontend JavaScript from accessing the cookie, reducing XSS attack risk.
   • SameSite=Lax or SameSite=Strict: Use Strict for maximum security (prevents the cookie from being sent in cross-site requests), or Lax if you need to allow cookie submission when the user navigates to the CDN from an app domain.
   • Path=/: Makes the cookie valid for all paths on your CDN.
   • Max-Age=86400: Set a reasonable expiration (e.g., 24 hours) based on your session needs.
3. Redirect the user back to the original app URL (from the redirect query parameter).

2.3 CDN Access Validation #

For every request to your CDN resources:

• Check if the request includes the valid auth cookie for personalCDN.com.
• If no cookie exists or it’s invalid, redirect the user to one of your app’s login pages (e.g., https://www.Application1.com/login?redirect=CURRENT_CDN_RESOURCE_URL). After login, the app will trigger the token redirect flow to set the CDN cookie.
• If the cookie is valid, allow access to the requested resource.

Your three app domains can’t share cookies directly, but you can sync their auth states using a shared authentication backend:

• All three apps should use the same auth service (either a dedicated auth server or a shared backend endpoint) to verify user credentials.
• When a user logs into Application1.com, the auth service creates a global user session. Application1.com sets its own cookie (e.g., Domain=Application1.com) for future requests to the app, then triggers the CDN token flow.
• If the user later visits Application2.com, Application2.com checks for its own cookie. If missing, it redirects to the shared auth service login. After login, Application2.com sets its own cookie and can optionally trigger the CDN token flow again to refresh the CDN cookie if needed.
• Key Rule: Never try to set a cookie for multiple independent domains (browsers will reject this). Each domain must manage its own cookie, while the shared auth service syncs user identity across them.

• Make one-time tokens single-use: Invalidate the token immediately after it’s used to prevent replay attacks.
• Keep token expiration extremely short (5-10 seconds) to limit window for hijacking.
• Use HTTPS exclusively for all login flows, redirects, and CDN requests to avoid plaintext data exposure.
• Avoid storing sensitive data in the CDN cookie; use a session ID that maps to user data stored securely on your backend.

内容的提问来源于stack exchange，提问作者Arnold Zahrneinder