Help with rebranding my OAuth app name

Google Cloud Cloud Foundations & Onboarding
1

Hi Google Developer Community!

First post here, so thanks in advance to anyone who reads this and apologies if this isn’t tagged appropriately.

I have a verified OAuth app that integrates with a variety of Google APIs. I am looking to update my app’s name that appears on the OAuth consent screen (via the “Branding” section of my OAuth app configuration in the Google Cloud console).

My understanding is that changing this will trigger a new verification review with Google, which is fine. My question though is will changing my app name cause users who have already authorized the application’s scopes to have to reauthorize?

I just want to make sure that doing this won’t invalidate any existing tokens for my users, requiring them to reauthorize. Everything I’ve read online implies that it won’t, but I am very cautious because this isn’t something I can practically test out beforehand or undo after the fact.

Thanks!

2

Hi @Ben_Hennessy,

You may refer to this documentation about the Changes to approved app:

  • If you make any modifications to your app’s name, logo/icon, redirect URI, homepage link, or privacy policy link displayed on your OAuth consent screen, your app will be required to complete brand verification again
  • If there are no changes to requested scopes, you will not be required to provide additional scope justification and instead can proceed to submit for verification.

Note: These changes will not be visible to the users till the app is reverified. These changes do not trigger the unverified app screen or the 100-user cap.

If you fail to submit your application for brand verification, it might result in decreased user trust of your request for their data, which can lead to fewer user authorizations and more revocations later. See also Submit for brand verification

These sources collectively indicate that updating the app name is a display-related change that triggers re-verification for compliance but does not affect existing user authorizations, as the tokens remain valid based on the unchanged client ID and scopes.