CODEWITHSUNDEEP
google-apigoogle-oauthgoogle-developers-console
Simona Galková
Simona Galková

Reputation: 13

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

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?

Upvotes: 1

Views: 1713

Answers (2)

pinoyyid
pinoyyid

Reputation: 22306

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.

Upvotes: 1

John Hanley
John Hanley

Reputation: 81424

I am seeking a recommendation as I cannot decide what is better:

I would align the Folder/Projects in the same structure as the company organization with a preference towards more projects (separation) instead of consolidation. Try to think of the chain of command and the distribution of resources. Factor in how you want security to separate resources. This might help figure out what should go where. Do separate development from production resources (separate projects).

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

The answer is "it depends". If they all share a common domain name root, and they authenticate at the root, very easy to implement. The authentication cookies can be shared across domains. Otherwise, you will need to use multiple redirect_urls so that auth on one site completes on the same site. I am not sure what the limit is for Redirect URLs per Client ID.

To the second part of your question "or they should not". If the websites are designed to look like the same company then customers will expect to only authenticate once and be authorized across all sites. Is this a good idea, Yes. Is it the correct idea, this depends on your security requirements, isolation needs, etc. No simple answer here.

Upvotes: 0

Related Questions