How can I Seamlessly Transition Google OAuth Between Two Domains?

Below is an overview of what you need to consider and an alternative strategy to minimize downtime:

---

Key Points

• Consent Screen Homepage vs. OAuth Settings:
  The “application homepage” URL in the OAuth consent screen is a display value and informational link. It does not itself enforce where requests come from. However, if you change it to domain B, users on domain A might be confused (or in rare cases have mismatches if you have any checks in your code).

• Authorized Origins and Redirect URIs:
  The OAuth flow relies on the approved origins and redirect URIs. As long as you list both domains for each client ID as you plan (i.e. add B to A’s settings and vice versa), Google will not reject the requests because of the domain differences.

• Client IDs Remain Unchanged:
  Reusing the same client IDs and secrets means that existing user tokens (issued for domain A) remain valid. There is no forced “re-login” simply because the consent screen URL changed, as long as the requests coming back match one of the allowed redirect URIs.

---

Considerations for Your Transition

1. Consent Screen Update Timing:
   When you update the consent screen (step 1) to list domain B as the homepage, this update is mainly cosmetic. OAuth will continue to work as long as the client IDs’ origins and redirect URIs are still valid.
   Caveat: If a user on domain A clicks the homepage link (or if any automated request validates the homepage URL), they may be directed to domain B. This could be confusing but shouldn’t break the OAuth handshake.

2. Interim Dual Support:
   By adding both domains to the Authorized JavaScript Origins and Authorized Redirect URIs for both client IDs (steps 2 and 3), you’re ensuring that requests coming from either domain will be accepted. This is crucial for a seamless transition.

3. User Experience Concerns:
   Even if the backend OAuth flow remains functional for domain A after the consent screen update, you should verify that no client‐side logic or deep linking in your application inadvertently forces a complete domain reference change before you’re ready.

4. Rollback and Testing:
   It’s a good idea to test the new configuration (in a staging environment if possible) before pushing it in production. Consider a short period where both domains are actively supported so that any edge cases (such as redirects from embedded links) can be caught.

---

Alternative Transition Strategy

Instead of immediately changing the homepage in the consent screen to domain B, consider the following:

• Step 1a:
  Update the OAuth settings (i.e., add B to A’s client ID and A to B’s client ID) and test that login flows work correctly from both domains.

• Step 1b:
  Once you’re confident that OAuth works from both domains, schedule a maintenance window to fully direct users to domain B. Then update the consent screen to reflect domain B.

This staged approach ensures that there is no sudden confusion or risk of a failing OAuth flow during the transition.

---

Final Answer to Your Concern

If you update only the application homepage in the consent screen to domain B (with all authorized origins/redirect URIs in place), OAuth should not “stop working” on domain A as long as:

• The client IDs in use still have domain A in their list of authorized origins and redirect URIs.
• No other logic in your application or Google’s review process enforces a hard match with the homepage URL during the OAuth flow.

That said, the change might be confusing from a user perspective. The safest approach is to ensure both domains are supported during the transition period and then fully switch over with clear communication to your users.

---

This plan—with the addition of dual listings during the transition—is correct, though consider the staged approach above to minimize any potential user confusion or unexpected behavior.