This guide has been deprecated and replaced with a newer version, which you can find HERE.

IMPORTANT NOTE:

Google OAuth

Verification Guide

Nylas’ comprehensive collection of tips, best practices, and necessary steps designed to maximize your odds for successful verification with Google’s OAuth team

​

Note: For use with Nylas API v2.7 and under.

For the Nylas API v3 verification guide click here

​

​

2

Table of Contents

01

02

03

04

05

06

07

Overview // Introduction // Recommendations

Sensitive vs. Restricted Scopes

Create Your Google Project

Create Your Demo Video

Checklist before Verification Submission

Whitelisting and Security Reviews

Helpful Tips // FAQ

​

​

3

Overview & Introduction

​

Helpful details re: Google’s OAuth Verification Process

​

​

1

4

Overview

Please note: This process is mandated and administered by Google, rather than by Nylas. We know the process is cumbersome; it’s unfortunately outside of our control!

​

​

In 2019, Google introduced its new OAuth Verification process, wherein third-party applications are required to submit an application to Google to verify your use of Google user data.

​

Depending on what data you use within your application, you might have to undergo Google’s app verification process, application whitelisting, and/or a security assessment.

​

This playbook focuses primarily on the steps you’ll need to take for Google’s verification process, which will allow you to leverage Google’s APIs in your application through Nylas.

​

We are not experts in building and configuring Google Projects, but we are here to help guide you as best we can through Google’s ever-changing landscape.

​

Our advice here stems from our experience assisting other Nylas clients with the verification process, and is designed to help ensure things go as smoothly as possible while requiring minimal back-and-forth with Google.

5

Introduction

In order to successfully undergo the verification process, you must first ensure that the following steps are complete:

​

1. Your integration is complete and live in your app’s production environment
1. Worried about pushing to prod? Consider putting this behind a feature flag in your application
2. The steps outlined in this guide are completed in full.
• (Along with any other Google-adjacent items unrelated to Nylas that you may need to complete within your Google Project)
3. Your demo video is recorded (more on this in Section 4).

​

Please be sure to thoroughly review this slide in particular prior to submission, to check for things that are often missed or misunderstood.

​

​

​

Note: After verification is submitted, it can take 2-8 weeks (or longer), depending on Google's submission queue and any remediation rounds required of you.

​

Please take care to complete all steps specific to your project in order to stay as close as possible to this projected timeline for approval.

​

6

Scopes

​

Available scopes, their purpose, and how to select the right ones for your project

​

​

​

2

7

Scopes

Before you create your Google Project, you’ll need to determine which Google scopes your app will use. Each scope grants you permission to access a specific piece/category of user data.

​

There are two types of scopes relevant to the Google OAuth Verification process: sensitive and restricted, the latter of which contains data requiring more stringent security controls.

​

• If you are using sensitive scopes only, you will only need to verify your app. �
• If you are using restricted scopes, or both sensitive and restricted scopes, you will need to verify your app and subsequently undergo a security review or whitelist.
• For more details on the security review process, please see this slide and reach out to your Customer Success Manager.

​

​

​

The following four slides outline the potential sensitive and/or restricted scopes you may plan to use for your Nylas implementation

8

Below is a narrowed list of Google scopes that Nylas projects utilize. You will need to select and add the appropriate combination to your Google Project based on:

1) Which APIs you’ve purchased from Nylas, and 2) Your specific use case.� �Choose only those that apply to your specific use case - ask your CSM if you’re not sure which are relevant for your project.��Link to help about scopes from Google’s help center.

Matching Google Scopes to Nylas Scopes

Both Nylas and Google present an array of scopes to correspond with specific use cases.

​

On the previous slide, we outlined Google’s scopes (selected via GCP) that are leveraged by - and relevant to - Nylas projects.

​

The next slide will detail the equivalent Nylas scopes that should be correctly matched to their Google equivalents. While many share similar or near-identical names, others are slightly more nuanced or differentiated; please pay special attention to these mappings.

​

These are the scopes that you’ll request via Nylas’ authentication APIs, which will in turn inform Google of what data you’re requesting. Google will cross-reference this against the Google scopes you request via GCP; they must match to avoid being served an error or having your verification request denied.

10

Not all Nylas scopes you’ll use in your integration match 1:1 with Google’s scopes and naming conventions.

Take a close look at the table below for details on which Nylas and Google scopes correspond with one another.��It’s important to confirm that the Nylas scopes you pass through in your code also correspond to the correct Google scopes below.��Link to Nylas Scopes

Always choose the most granular scopes needed in your Google Project or Google will deny or delay your verification. ��You need to ensure that your scope requests correspond to your app’s functionality in the most granular manner possible. When applicable, you will only want to request the parent scopes for specific functionality.

​

Below are all of the Nylas scopes that have ‘child scopes’ underneath them. For example, if you ask for email.readonly in Nylas, this encompasses email.metadata. When selecting the needed scopes in your Google Project you’ll only need to add email.readonly as it will include email.metadata by default.

Scopes

​

Take care to ensure the scopes you enter in the GCP console (see slides in Section 3: “Create your Google Project” for guidance on how to add those scopes) and the Nylas Scopes you are using in the Nylas Hosted Auth or Native Auth calls ALL match for your use case.

​

​

​

​

�Scopes: �Nylas Auth Call scopes

vs

Scopes added to Google GCP

vs

Application use case

​

​

Note:

• Google will reject your submission if these do not match.
• See guides above for example codes and replace scopes with those needed for your application

13

Create your Google Project

​

​

Step-by-step instructions & screenshots for configuring GCP

​

​

​

​

3

14

Create Your Google Project

​

​

Step 1 -> Create your Google project:

1. Create an account on the Google Developers Console, and create a new project OR use an existing Dev/Staging & Production Google project.
1. Highly Recommended: Create a Google Project for your staging/dev and production separately as Nylas applications can only have one Google Project assigned to them.
1. We also highly recommend having a staging/dev and production application in Nylas as well to correspond with the above Google Projects.
2. Naming your Google Project:
• Please include your company name, as well as ‘dev’ or ‘production’, in the title of your project so we can easily identify it.

Example GCP name: CompanyName Nylas Prod

​

Note: This walkthrough is designed to help with items that:

1. Are directly correlated to your Nylas integration
2. Reflect what we have seen in practice to help ensure a smoother Verification process

Please keep in mind that there may be other items that need to be addressed in your Google Project that are unrelated to Nylas and thus are not covered in this playbook.

15

Navigation Menu -> APIs & Services -> ‘Credentials’:

1. Create ‘OAuth Client ID’ credentials to access your enabled APIs
2. Then, add the Client ID and Client Secret to your Google OAuth details in the Nylas Dashboard under (shown on next slide) if using Nylas Hosted Auth or to the auth API call if using Nylas Native Auth

In your Nylas Dashboard, Select your Application from the dropdown in the upper left navigation bar.

App Settings -> Authentication -> ‘Google Auth’:

​

• Add the Client ID and Client Secret from the Google Project to your Google OAuth details in the Nylas Dashboard under ‘App Settings’.
1. Only needed for Nylas Hosted Auth
• Each Nylas application can only be associated with one Google project.
• Ensure the Google Project for your production is added to your Nylas production app and the same for the Dev/Staging as each Nylas

Navigation Menu -> APIs & Services -> Library:

​

Search for and enable all API Libraries that you will need: Gmail API, Google Calendar API and/or People API.

​

Note: You will only be enabling APIs that correspond to the scopes that your app will utilize.��

​

Search for the set of scopes needed in your application and enable

Navigation Menu -> APIs & Services -> Dashboard:

​

This is where you can check and verify the full list of APIs you have enabled within your Google Project

​

​

Navigation Menu -> IAM & Admin -> IAM:

Next, add Nylas as a Project Owner through the entire duration of the Verification Process.

​

Steps:

• Click Add�
• Add support@nylas.com as a Project Owner.
• The Nylas team will subsequently accept the invitation. This verifies that we authorize the the ‘nylas.com’ domain, which is required for hosting the authentication flow.
• Let your CSM know that you have completed this, and please include the Name of your Google Project.

Why this is important:

• Allows Nylas to review your project to ensure its accuracy
• Google requires that all Authorized Domains listed must also be listed as Project Owners with the matching domain. Otherwise, Google will flag this and ask you to verify these domains.

**please note that this is required process for hosted authentication, if you are using native authentication, please work with your CSM directly

​

Navigation Menu -> APIs & Services -> OAuth Consent Screen:

During implementation you may keep your Google Project in a few different states.

• ‘User Type’ as ‘Internal’: In this mode, your app is limited to Google Workspace users within your organization
• ‘User Type’ as ‘External’ & ‘Publishing Status’ as ‘In Testing’:
• Note: While ‘In Testing’, you need to add Test Users. Tokens expire in 7 days and require users to re-auth.

​

​

Click here to learn more about the Publishing Status

Click here to learn more about User Types

​

​

• Enter your Application Name
• User Support Email
• Used for users to contact you with questions about their consent. We recommend using an alias or distribution list with several relevant parties included.
• Add your app logo

​

​

​

Navigation Menu -> APIs & Services -> OAuth Consent Screen -> Edit App ->

OAuth consent screen section -> App Information:

​

​

​

• Add your:
• Application Homepage URL
• Google requires that this is a true homepage - it cannot be a ‘login’ page only.
• Application Privacy Policy link
• Important:�Ensure your legal team reviews your Privacy Policy and it meets Google’s specific requirements from the ‘Limited Use’ section of that hyperlinked document. This step can be time consuming.
• Application Terms of Service Link

​

​

Navigation Menu -> APIs & Services -> OAuth Consent Screen -> Edit App ->

OAuth consent screen section -> App Domain:

​

​

• Add the production-level domains you are utilizing in your Google Project.
• Your domain must be your production-level domain (not dev/staging domain)
• Add the Nylas.com domain (see this slide) if you are using hosted authentication. If you are using native authentication, you do not need to add nylas.com
• Note re: Multi-tenant setups:�If your application is setup with a multi-tenant architecture, ensure the individual domains that you use and are offered per client are subdomains.
• If so, enter the main domain here and under ‘Authorized Domains’ in the ‘OAuth Consent Screen Section’.
• If not, each domain will need to be added separately, and this may cause issues

​

​

​

Navigation Menu -> APIs & Services -> OAuth Consent Screen -> Edit App ->

OAuth consent screen section -> Authorized Domains:

​

​

​

​

• Enter an email address.
• This should be a distribution list email address to ensure all parties receive Google Verification related emails and all emails sent from Google to notify you about any changes to your project. Make sure to keep this distribution list up-to-date as team members come and go.

​

• IMPORTANT:�Once you submit for verification (more on that later), keep a close eye on the the Google project to see if there are any action items from Google.
• They will send emails to this address, but they can sometimes end up with your spam folders or be blocked by your servers all together.

​

Action items during the Verification process will appear here:�

​

​

Navigation Menu -> APIs & Services -> OAuth Consent Screen -> Edit App ->

OAuth consent screen section -> Developer Contact Information:

​

​

​

Select the ‘Add scope’ button to access the menu.

Add required non-sensitive scopes:

• openid
• /auth/userinfo.email
• /auth/userinfo.profile

Disclaimer - You may or may not need other scopes for your native integration that don’t apply to your Nylas integration.

Please refer to the following slides A, B, & C to confirm which scopes you need.

Navigation Menu -> APIs & Services -> OAuth Consent Screen -> Edit App -> Scopes section -> ‘Your non-sensitive scopes’:

​

​

Select the ‘Add scope’ button to access the menu.

Your scopes will vary depending on your application’s needs. To see a list of Sensitive scopes see slide

For sending emails only:

• ./auth/gmail.send

For read only access these are the corresponding scopes to choose from:

• ./auth/calendar.readonly
• ./auth/contacts.readonly

For access to do more than the Parent scopes are needed:

• ./auth/calendar
• ./auth/contacts

​

​

Example: full bi-directional CRUD operations for both Calendar and Contacts:

Navigation Menu -> APIs & Services -> OAuth Consent Screen -> Edit App ->

Scopes section -> ‘Your Sensitive scopes’:

List of Sensitive Scopes and their functionality:

Disclaimer: You may or may not need additional scopes for your native integration that don’t apply to your Nylas integration

​

​

​

If Applicable for your application and you are using Restricted Email scopes, please reference slides 8, 9, & 10:

• Slide A - to learn about what scopes are available and if they are restricted or sensitive
• Slide B - how Google scopes match to Nylas scopes are there is not 100% parity
• Slide C - Nylas Parent/Child relationships to help chose the most granular scopes needed in your Google Project

​

Select the ‘Add scope’ button to access the menu.

Disclaimer: You may or may not need additional scopes for your native integration that don’t apply to your Nylas integration. If your application requires restricted scopes (meaning you need any scopes other than the sensitive scope ‘gmail.send’) you will need to go check out Section 6 of this playbook ‘Whitelisting and Security Reviews’

​

List of Restricted Scopes and their functionality:

Navigation Menu -> APIs & Services -> OAuth Consent Screen -> Edit App -> Scopes section -> ‘Your Sensitive scopes’:

REMEMBER: Be sure to ask for parent scopes related to only the scopes you need — if you request ones that are not utilized in practice within your app, it will result in your application being returned by Google for your review.

​

If you are confused about which scopes your app utilizes, reach out to your Customer Success Manager for help or reference the help guide from Google.

​

Link to help about scopes from Google’s help center.

​

​

29

Once the finalized demo video is created and a Google Project is completed, you are ready to submit for Verification after these steps:

1. Set the ‘User Type’ as ‘External’ & ‘Publishing Status’ as ‘In Production’. This opens additional fields in your project (ex. Demo video)�Note: you have 100 user cap before you need to have a verified Google Project to auth any more users into your application.
2. Fill out the “How will these scopes be used?” sections, explaining the same functionality that you show in your demo video.�Google requires it to be formatted as follows: “https://mail.google.com/ [insert your app name] to read and compose from Gmail [insert your app’s functionality]. I will need read in order to____ so that my app can ____. I will need compose in order to ____ so that my app can ____ . A narrower scope would not be sufficient because ____.”
3. Link to the video uploaded to Youtube as an ‘unlisted’ video
4. Click Submit
5. Look out for emails from Google sent to the email under Developer Contact Information

Navigation Menu -> APIs & Services -> OAuth Consent Screen -> Edit App -> Scopes section -> ‘How will the scopes be used’:

Create your Demo Video

​

​

​

​

Create and host a demo video that adheres to Google’s requirements

​

​

​

​

​

​

4

31

Verification video explainer

Timestamps:

​

00:00 Introduction

00:30 GCP App setup

01:07 GCP App scopes

02:23 How to demo scopes

02:47 Removing existing app access

03:10 How to approach your video

03:53 Highlighting the clientID

04:28 Calendar scope justification

06:29 Sample verification video

​

Note: You only need to submit your own video in the style of our sample - you don’t need to cover the GCP App set up

Video link: https://www.youtube.com/watch?v=oNIKp5SkHDE

​

32

Demo Video

​

You will also need to submit a video demonstrating your app’s functionality in order to verify your app with Google. This must be uploaded as an ‘Unlisted’ Youtube video in order to submit for verification. Only one video link is allowed.

Before you create the video, confirm that:

• Your app and OAuth flow is shown in English (seen in Google docs here under “Apps requesting sensitive scopes” and “Apps requesting restricted scopes”)
• It is in the production-level domain
• Google Project is set to the following under Navigation Menu -> APIs & Services -> OAuth Consent Screen
• Publishing status = In Production
• User Type = External

​

​

​

​

33

Official Google Sign-in button

The official Google sign in button must appear somewhere within your OAuth flow (and demo video) as the call to action to connect a Google user’s account. Link to Google’s Sign-In Branding�� OR�

Using Nylas Native Auth?

​

• You must ensure that your application includes the official Google Sign-In button (as shown above) within your native UI.

​

Note: You’re free to incorporate multiple provider-specific login buttons, as in the example below.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Using Nylas Hosted Auth?

• Please navigate to the NEXT SLIDE for guidance.

​

Related Slide: “During Verification Process: Google Request for test account”

​

34

Official Google Sign-in button

Using Nylas Hosted Auth?

A few different scenarios dictate the required course of action for hosted auth flows:

​

• Do you have access to a Google Workspace (f.k.a. GSuite) account for purposes of recording your demo video? If YES, use this account to record your demo.�
• In this case, you do not need to add the official Google button to your native UI
• The Nylas Hosted Auth flow incorporates the official Google button by default, so this will appear in your demo video when authenticating a Workspace account

​

​

​

​

​

​

​

​

​

• DON’T have access to a Google Workspace (f.k.a. GSuite) account for recording your demo video? (e.g. you only have a gmail.com address):

​

• You do need to add an Official Google Sign-In button to your UI, per the previous slide�
• You must collect the user’s email address via a field in your UI, in order to pass this detail through as a ‘login hint’ when the user clicks the official Google button.�
• This prevents redundant or confusing UX elements in your auth flow that can result in conversion drop-off
• See login_hint string under ‘query-string parameters’ for guidance on how to incorporate

​

Related Slide: “During Verification Process: Google Request for test account”

​

35

Demo Video

We highly recommend that you do a voice over, explaining what you’re doing during each step of your video demonstration to help make it as clear as possible to Google what is being shown on screen.

Please ensure you cover:

Authentication:

• Show your application’s homepage with the full URL, showing that it is in production
• Once you are in the application, show how a Google customer will connect their account
• Ensure you have the official Google sign-in button mentioned in the previous slide
• During the auth flow, when you are in the screen showing the OAuth process, highlight the URL and drag across to show the CLIENT ID in the URL (here is an example video).

Functionality:

• Show each set of scopes being requested, one at a time: email, contacts, calendar (note: your use case determines the relevant scopes)
• Show bi-directional functionality and demonstrate syncing between both the application and provider. Have a tab open with your Application and with each part of Google to toggle back and forth between the two.
• Example of what to show for a Contacts integration using the scope: /auth/contacts:
1. Show that the contacts in your application match that in Google Contacts
2. Show you editing a contact in your application and it syncing to Google and vice versa
3. Show you creating a contact in the application and it syncing to Google and vice versa
4. Show you updating a contact and deleting a contact

36

Demo Video

Once you’ve created your video demo and have confirmed it meets all criteria listed in the prior slide, please send the YouTube video URL to your Customer Success Manager, who will help review. Then, you can submit your app for verification.

​

The final video must be added to your Google Project as an ‘unlisted’ YouTube video link.

​

After submission, it can take 2-8 weeks depending on Google's submission queue and the amount of remediation rounds they require you to undergo.

37

Google’s First Reply Upon Submission for Verification

​

​

Upon first submission to Google Verification, Google now sends this standardized questionnaire.

​

Please respond to each question thoroughly as this is the pre-cursor to beginning with the verification process.

​

If you fall into any of the categories described, your app does not require completion of the Verification process.��Learn More here from Google under:

“Exceptions to verification requirements” drop down

​

​

38

Checklist for Verification Submission

​

​

​

​

A handy list of items to double and triple-check before submitting to Google for verification. Please review carefully.

​

​

​

​

​

​

​

​

5

39

Verification Checklist

Project Owner (slide):

• Is support@nylas.com listed as a project owner?

OAuth Consent Screen Section (slide):

• Is your app marked as “In Production” Publishing Status and “External” User Type?
• Does your App Information contain the following? (slide):
• App Name
• User Support Email (for users to contact you with questions about their consent).
• Logo
• App Domain (slide):
• Application Home Page
• Application Privacy Policy Link (ensure to have included the limited use section mentioned in slide)
• Application terms of service link

CONTINUED ON NEXT SLIDE

​

Google Project Checklist:

​

​

40

Verification Checklist

OAuth Consent Screen [CONTINUED]:

Authorized Domains (slide):

• Nylas.com
• All of your production-level domains

Developer contact information (slide):

• This should be a distro email address (This ensure all parties receive Google Verification related emails and all emails sent from Google to notify you about any changes to your project)

Scopes Section:

• Are all the required non-sensitive scopes added (slide) ? (Note you may have others needed for your use case outside of Nylas)
• openid
• userinfo.profile
• Userinfo.email
• Are the Sensitive & Restricted scopes added as needed for your use case? (3-slides)
• Is the “How will these scopes be used?” section filled out? (slide)
• Is your youtube demo video created and linked (6-slides)?

​

41

Verification Checklist

• Video is in English (seen in Google docs here under “Apps requesting sensitive scopes” and “Apps requesting restricted scopes”)
• In your Production-level application environment
• Shows your homepage with the production-level URL
• Has an official Google sign-in button branded icon or button
• Highlights ClientID in OAuth Flow directly in the URL which matches the Google Project being submitted for verification
• Demonstrates bi-directional functionality and it syncing between both the application and provider of scope(s) being requested in the Google Verification process for each API and each functionality (ex. Create, read, modify, delete, etc.)
• Upload an ‘unlisted’ Youtube video to link in the Google Project for submission. Google only accepts videos in this format.

After submitting for verification, Google may ask to test your app’s functionality and you will receive an email asking:

“If your app requires registration or features a local login:

• Please whitelist or authorize our test email account exampletest@gmail.com - this will let us test your app’s functionality. **note that Google will provide you with a test account, this is just an example
• OR provide us with a username and password of a test account”

Verification Demo Video Checklist:

42

Verification Checklist

• Your privacy policy discloses your use of Google API’s:
• Sample disclosure: “(App’s) use and transfer to any other app of information received from Google APIs will adhere to Google API Services User Data Policy, including the Limited Use requirements.”
• Your privacy policy discloses the use of any AI models (and an ability to opt out, if possible).

Your Terms & Conditions:

43

FYI: Annual Reverification

​

​

​

Google’s verification process is largely a one-time lift until you make any additional changes to your application and GCP project after initial verification, e.g. adding or removing scopes (which do require that you undergo verification once again and justify any changes you’ve made).�

However, it’s worth noting that in some cases, particularly when leveraging restricted scopes, Google may require you to make some small updates to your verified project on an annual basis, e.g. adding brief disclosure verbiage or other similar changes. This typically requires very minimal additional lift and is vastly quicker than the initial verification process, but is worth looking out for. �

These requirements are typically communicated via the developer email that you input in the OAuth consent screen section, so take care to ensure that this is up to date!

44

Whitelisting & Security Review

​

​

If you’re using restricted scopes, there’s still more to be done. Here’s a quick primer of what to expect next.

​

​

​

​

​

​

​

​

​

​

6

45

Google �Annual Security Assessment

​

​

To help keep user data safe, every app that requests access to restricted scope Google user’s data is required to go through a security assessment. This assessment helps keep Google users’ data safe by verifying that all apps that access Google user data demonstrate capability in handling data securely and deleting user data upon user request. The assessment process is described in detail on the CASA (Cloud Application Security Assessment) site.

CASA assessment can take up to 6 weeks depending on how engaged and responsive you are in the whole process. We strongly suggest you get started with the assessment as soon as possible.��Google will categorize your App as either Tier 2 or Tier 3:

• Tier 2 Authorized Lab Scan
1. Note: Previously able to self-scan but now must use a CASA authorized Lab
• Tier 3 CASA Assessment
• opt-in to complete a Tier 3 assessment by contacting CASA authorized TAC Security, or any of the CASA authorized labs. CASA Tier 3 is a comprehensive assessment that tests the application, the application deployment infrastructure and any user data storage location.
• Tier 3 assessments have the following benefits:
1. Conducted and validated by the authorized labs giving your application high assurance of compliance with CASA standard
2. If your application is listed on the Google WorkSpace Marketplace you will receive an independent security verification badge

Google Security Assessment Information �(**scroll down to the Security Assessment FAQs for more detailed info)

Useful resources:

Refer to the following documentation for more information:

• CASA Website
• CASA Tiering
• Other Tiers Process

​

46

Yearly Security Re-assessment

Apps accessing restricted scopes are required to reverify their app for compliance and complete a security assessment every 12 months to keep access to any verified restricted scopes.

If at any point you add a new restricted scope that wasn’t previously assessed and approved, your app may need to be reassessed at that time.

The Google review team will reach out to you via email once it’s time for your app to recertify. Keeping your Project Owner and Project Editor information up-to-date in your Cloud Console will ensure the right members of your team are notified of this annual enforcement.

​

Google FAQ: How long is the security assessment valid for?

47

Whitelisting

If you would like an alternative to the verification & security review processes, you may also opt to have your application whitelisted. If you meet a very specific set of criteria, this would allow you to bypass the verification and security review process. Though most use cases do NOT meet this criteria, we’ve outlined the requirements here so you can determine whether it might be a fit for your application.

Requirements:

• The vast majority of your customers use Google Workspace (formerly GSuite) accounts (i.e., @businessname.com addresses)�
• All Google Workspace users must have their admins whitelist the application for this to work - so this route does require action by your end users.

​

• Fewer than 100 personal Gmail accounts (@gmail.com addresses) can auth into this flow (these accounts are not able to be whitelisted)�
• Unverified projects have a 100 (lifetime) user limit per project. When whitelisted, Google Workspace accounts that are whitelisted do not count against this limit. Personal Gmail accounts always will, however, so be mindful of this limit if you decide to proceed with whitelisting as a workaround solution

​

• Free Trial users must use their Workspace email address and whitelist the application�

Please consult this whitelisting guide for additional details, and contact your Customer Success Manager if you have further questions.

48

Helpful Tips & FAQs

​

​

​

​

A few helpful points that customers sometimes miss or ask us about. We’ll add to this section over time.

​

​

​

​

​

​

​

​

​

​

​

​

7

49

Helpful tips often forgotten

In order to reduce the likelihood of Google returning your app for re-submission, make sure your app adheres to the following guidelines:

​

1. Your Google sign-in button adheres to Google’s branding
2. Your app homepage clearly shows your app’s brand and identity, and does not route to a direct login page
3. Your Privacy Policy meets Google’s specific requirements specifically from the ‘Limited Use’ section of that doc
4. You have only requested the required scopes that correspond with your app’s available functionality, without unnecessary redundancy (see slides 8 - 10).
5. You have double-checked that the Nylas scopes you request during the OAuth consent process match those that you’ve requested in your Google project (See slide 9).

​

50

Helpful tips often forgotten

Google Test Account:

• Google may ask for a test account, or to whitelist a specific email address* in order to test your application (as shown in this sample screenshot):�

����

​

​

��

(*provided email address may vary)

​

​

Using Nylas Native Auth?

• Either whitelist / authorize the test email Google Providers
• OR
• Provide them with a username and password of a Google WorkSpace test account�

Using Nylas Hosted Auth?

• You must provide them with a username and password for a Google Workspace test account, rather than whiteslist their account.
• This will ensure that Google is served the required official sign-in button, a requirement for successful verification.
• Whitelisting a Google test email instead will result in pushback and verification difficulties when using the Nylas hosted auth flow.
• Note: If your application has a built-in Official Google Sign in Button then you can whitelist / authorize the test email Google provides, if preferred.

​

Related to Slide: “Demo Video: Official Google Sign-In Button Recommendations”

51

Making Changes to your Project

​

​

​

​

If at any time after your initial verification you choose to add or change any of your previously-verified scopes or try authenticating with unverified scopes, this will immediately trigger a re-verification requirement from Google. As part of this process, you’ll need to re-record your demo video to reflect your app’s new functionality, along with all existing functionality as you did previously.

During this process, users who have a current valid auth token and net-new users authenticating against previously-approved scopes will not have their experience interrupted. ��Net-new users attempting to auth against your newly added scope(s) prior to re-verification (as a result of the calls you’re making via Nylas auth APIs) will be served an ‘app not verified’ or ‘application blocked’ warning.

​

• This message will persist until re-verification is complete, so many clients elect to alert their support teams to anticipate an influx of questions about this.

Note that when adding new restricted scopes, you’ll need to undergo this re-verification process AND will need to complete a Security Assessment in conjunction with an approved security assessor, effective immediately. This is true even if you previously leveraged restricted scopes and already previously completed an assessment at that time.

Changing, Updating, or adding scopes to a previously verified Google Project

52

Frequently Asked Questions

​

​

Why does Nylas need ‘project owner’ access to my GCP Project?

• Google needs to confirm that an authorized project owner is associated with the same @nylas.com domain name and that they match.

​

How long does the verification process take?

• This varies considerably, but generally we advise budgeting 2-8 weeks for completion.

​

Do I need to undergo a Security Review in addition to Verification?

• Google’s Security Review process is a required step for any application that uses restricted scopes: namely, any Gmail scopes other than gmail.send and gmail.labels

​

How is gmail.modify different than other gmail scopes?

• In addition to the permissions afforded by child scopes gmail.compose, gmail.readonly, and gmail.send, parent scope gmail.modify also allows you to use trash, labels, or metadata.

​

Google rejected my project, but the reasons they provided are not accurate / my app already adheres to their requests. What gives?

• This is not uncommon. We recommend sending a thorough email reply with screenshots, or that annotates exactly where in your demo video you’ve demonstrated compliance (with timestamps). Often they’re simply mistaken.

​

​

​

​

​

​

​

​

​

​

53

Frequently Asked Questions

​

​

Is there an optimal time to submit for verification or re-verification?

• Some GCP reps have suggested that Mondays are potentially the best day to submit for quickest turnaround, but your mileage may vary.�

What happens if I call a net-new Google scope in my application without submitting for re-verification in my GCP project?

• Your app will promptly be blocked, and users will not be able to authenticate until you revert the change. Please avoid this.

​

I’ve exceeded my 100 test user cap, but need to revert my project to ‘testing’ to make a change. How do I record a new demo video if I can’t auth new users?

• Please contact GCP via your project-specific email (see below), clearly explain the situation, and provide a contact email address with a request to have them whitelist it for purposes of recording a new demo video.

​

I have a problem with my GCP project, or specific questions for Google about the verification process. Who should I contact?

• For any projects that have previously been verified, or that have an ongoing verification process underway, Google will communicate with you by way of a project-specific email address in the following format:
• “api-oauth-dev-verification-reply+[uniqueprojectIDstring]@google.com��This is the optimal contact method for direct feedback from Google. If you don’t already have existing communications from GCP via a similar email address, oauth-feedback@google.com is a secondary option, albeit with generally slower response times expected.”

​

​

​

​

​

​

54

Final Guidance

​

​

​

​

​

​

Google would like to have the partner - that’s you - reply via the communication email thread during verification process. All emails are sent to the Developer Contact Email you filled out earlier in this process.

​

​

For further info, check out this Google link -> Google’s OAuth API verification FAQs

​

​

Need more help?�You can also open a ticket with Google using this email: oauth-feedback@google.com prior to submitting for verification if you have any questions or need further guidance on setting up your Google Project.

55

Nylas.com Github.com/Nylas @Nylas