Create one or multiple projects for OAuth 2.0 for the company websites in different countries? (different prefix in URL and local content)

Question

I am developing a structure in Google developer console to create projectsnd configure a OAuth 2.0 client IDs for our company websites. These we use to integrate Google login to the website.

We have around 50 websites now, where some are "company websites", then we have "product websites", etc. such groups.

For example group of company websites - those websites have exactly the same design, the same purpose, but are country specific, thus: - differ in country prefix, e.g. countryA.companyxy.com, countryB.companyxy.com - differ in content (types of content are the same, but the ontent itself is connected to the country, thus local) - the language can be different (although mostly it's english)

I am seeking a recommendation as I cannot decide what is better: 1) Create one project per website and then different Client IDs for environments (prod, staging, dev) - this would be 50 projects, each with 3 Client IDs 2) Create one project per a group - e.g. company websites would have one project and I would create new Client ID for each country and each environment. This way I would have maybe 5-6 projects, each with 10-20 Client IDs.

Can those company websites all use the same application, or they should not?

Answer 1

If I've understood you correctly, this is a fairly standard multi-tenant application where a single app (from Google's perspective) lives at multiple domains. You can use a single Project and a single Client-ID, since in both cases, the ID relates to the app, not to the domain the app lives at.

So, when you start the OAuth dance, you always specify the same redirect URL, which handles OAuth for all domains. The trick is that you include a state parameter at the start of the dance which indicates which country/site your OAuth code should redirect to once the dance is finished.

So, roughly something like this:-

1. user visits countryA.companyxy.com and requests Oauth (eg. clicks a signin button)
2. You redirect to accounts.google.com?redirect_uri=common.companyfoo.com/oauth&state=countryA.companyxy
3. After auth, google will redirect back to common.companyfoo.com/oauth?state=countryA.companyxy
4. Your oauth handler does its thing, then parses the state param and redirects back to countryA.companyxy.com

Of course there might be administrative reasons for your company to prefer multiple projects and/or client IDs depending on your enthusiasm for admin, and how you wish to segment your data. To explain this last point using Drive as an example, if all companies have the same project, then the drive.file scope would give them all access to the files created by the app. However, if you have a project for each company, then Google sees these as created by different apps, so the are not visible using the drive.file scope.