Calendar management
Embedded contextual email
Scheduling automation
Automated outreach
Telehealth
Marketplaces
Recruiting
Document management
Real estate
Communications software
Docs
SDKs
Tutorials
API status
Changelog
Support
Blog
Events
Guides
Newsroom
Partners
Build vs. buy
Customer stories
Trust & security
Why NylasPros and cons of using shared vs. private Google Cloud Projects for OAuth
Unpack the benefits and trade-offs of shared versus private Google Cloud Projects for OAuth, with a focus on security, system availability, and maintaining identity.
Unpack the benefits and trade-offs of shared versus private Google Cloud Projects for OAuth, with a focus on security, system availability, and maintaining identity.
Google Cloud Projects offers an array of tools and integrations that can supercharge businesses, and here at Nylas, that’s no exception; our email, calendar, and contacts APIs offer quick and powerful development solutions with Google’s Workspace APIs. But when diving into integrations — namely OAuth, clients, and scope grants — an important crossroad emerges: should you use your own dedicated Google Project or join a shared one provided by third-party services?
For those unfamiliar with OAuth and project scope grants, let’s break it down. OAuth is a widely used protocol that allows third-party applications to access user information without compromising the security of the user’s data. In the realm of Google Cloud, this translates to applications like Nylas being able to interact with services such as Gmail, Google Calendar, and Google Contacts on your behalf, once the appropriate permissions are granted.
Scope grants, on the other hand, determine the level and type of access an application has to your data. Think of them as the permissions you give when installing a new application on your smartphone. It’s the fine print that says what the application can or cannot do. In Google’s environment, this might mean granting read-only access to your emails or allowing full edit capabilities to your calendar events.
Because sensitive data can be accessed through OAuth, Google makes a point of having the infrastructure/system verified through them before allowing the issuing of grants. For some highly restricted access scopes (i.e., email), they even require a security review.
Now, back to the dilemma at hand: should you set up a dedicated Google Project or opt for a shared one?
With your own Project, you have total control over your data and the privacy measures you have in place. Things like breaches and data loss are self-contained, and you don’t need to hand over trust and control to another company.
First and foremost are the quota limits in Google Cloud. Albeit being fairly high and adjustable, the more tenants that live in a single shared Project, the more likely rate-limiting and throttling are to occur. This can affect your application, even if you aren’t getting particularly high traffic.
Secondly, a single, shared cloud Project can lead to a less resilient system. Of course, this all depends on how your architecture is set up; if you want dev, stage, and prod to all be completely isolated, or if you want a completely separate disaster recovery Google Cloud Platform (GCP) Project, then private Projects allow you to do that at will. Having the ability to make multiple Projects for your application is never a bad idea to ensure high performance and increased reliability.
If you rely on the Google security verification of a shared Project hosted by a third party, it adds another risk to your application flow. If that third party gets their verification status revoked, or if any rules or terms of use are broken by either them or one of their numerous tenants sharing the Project, it can drag your application unjustly out of service.
If brand identity and reputation are important to you, then having your own Google Project allows for white labeling — the use of your own domain, logo, and whatever else makes up your identity. In contrast, third-party hosted Projects will be operating under the Project owner’s brand, which makes for less seamless (and sometimes confusing) user experiences.
If you choose to migrate to your own Project after establishing yourself on a shared Project first, all your users will need to re-authenticate and accept terms over again. Indeed a minor detail, but a factor to consider for a seamless user experience.
System up-time is another important item to note. Offloading part of your application to a third-party Project leaves you at the mercy of using another dependency, which can affect your SLAs and reliability.
Using shared Projects that have already been verified by Google reduces your TTL. This is super useful for sandbox or small-volume applications.
How does it do this? For starters, there’s one less account you need to manage. The crux, however, is the verification process Google has. The review process needed is determined by scope type, either sensitive or restricted. This means that things like calendar integrations require less of a review process than things like email integrations (which access more scopes), which require a full security review.
As a result, some use cases have simple and quick (2-3 week) verification processes. You can refer to our Google verification guide to determine what your use case might need.
Your team will have one less Google Project to worry about, which reduces the overhead against your engineers. This management load is typically lighter, albeit ongoing, and typically involves monitoring user permissions and policy updates. Of course, this is at the exchange of control, but some organizations are just fine with that.
This goes hand-in-hand with reduced management and TTL; your team has one less step to get off the ground running. However, always make sure to consider the long-term vision for your product to ensure that you don’t lock yourself into the wrong solution!
No, Nylas customers are not on a shared Google Project. Using your own Project gives you control over scopes and how your end users share data, de-risks reliability by siloing risks from other organizations, and gives ability to control your custom brand identity.
Check out the Nylas guide for Google’s verification and security assessment process, or connect with a Nylas expert.
Please enter your email address and receive the latest updates.
Antoine is a Technical Product Manager at Nylas. Before Nylas, he spent a few years working as a developer in the cloud and security spaces. He's passionate about technology and shaping products, and in his free time enjoys learning about new things, traveling, and boxing.
