现有OAuth应用能否新增域名？更换域名相关技术问题咨询

Great question—this is a super common scenario when moving apps to new domains, and the answer has clear distinctions between Google and Microsoft’s OAuth systems. Let’s break down each part step by step:

1. Do I need to create a new Client ID and Secret after switching domains? #

Short answer: No, you don’t need to create new credentials for either provider. You just need to update the existing Client ID configuration with your new domain’s redirect URIs.

• Google OAuth
  Head to your Google Cloud Console, navigate to API & Services > Credentials, find your existing Client ID, and edit its authorized redirect URI list. Add the new URI(s) for your domain (make sure to match HTTPS/HTTP exactly, plus any port numbers if applicable). You can keep the old URIs temporarily for a smooth transition, then remove them once the old domain is no longer in use.

• Microsoft Entra ID (Azure AD)
  In the Azure Portal, go to Microsoft Entra ID > App registrations, select your app, and open the Authentication tab. Update the redirect URIs under the relevant platform (e.g., Web) to point to your new domain. Like Google, you can maintain both old and new URIs during migration to avoid breaking existing login flows.

2. Will existing users who granted mail read/write permissions need to re-authorize after updating the redirect URL? #

Short answer: No, existing users won’t need to re-authorize unless you change the permission scopes or their tokens are invalidated for unrelated reasons.

• Google OAuth
  User authorizations are tied to your Client ID and the permission scopes you requested—not the redirect URI. As long as you keep the same Client ID and don’t add/remove scopes, existing refresh tokens will still work to fetch new access tokens. If a user needs to re-authenticate later (e.g., when their access token expires), the login flow will just redirect to your new URI (which you’ve already configured) without requiring them to re-grant permissions.

• Microsoft OAuth
  Similarly, Microsoft’s authorization tokens are linked to your app’s Client ID and the user’s account, not the redirect URI. Your app can continue using existing refresh tokens to access mail APIs as long as the permission scopes remain unchanged. The only time users would need to re-authorize is if you add new permissions that weren’t part of the original grant.

Quick Pro Tips #

• Keep both old and new redirect URIs active during your migration window to avoid disrupting users who might still access the app via the old domain.
• Double-check that your new domain uses a valid HTTPS certificate—both Google and Microsoft require secure redirect URIs for production apps.
• Test the flow with a test user to confirm the new redirect URI works, tokens are issued correctly, and mail API calls still succeed without re-authorization.

内容的提问来源于stack exchange，提问作者CCE Imynd