For some reason, I’ve implemented oAuth way more times than I imagined I would when I started my career. I recently had to go through the Google login flow again. As a company that holds so much data on its user, Google has rightfully tightened the rules on who can implement Google Login. I’m not sure if it has anything to do with GDPR or CCPA, but things seem to have changed a lot over the last couple of years (2018/2019).
If you are embarking on a journey to implement Google Login, I hope this blog post will help you with planning out the project, so it doesn’t have to delay.
Figure out the type of user data you’re accessing
Google uses a lot of scopes for each type of permission, and you’ll need to apply for it at the beginning of the project. It can take Google weeks to approve the scopes you apply for, so do this research now or regret it later.
Here are some more things all apps need to do concurrently before writing any code:
- Verify with Google that you own the domain you’re implementing Google Login with. To do this you’ll have to go to Google Search Console, of all places. After entering your domain, Google will give you a string to paste into the TXT record of your domain.
If your project is on multiple platforms (Web, Android, iOS, etc), create a different Google app for every platform.
Chances are, even the same app can require different scopes on different platforms. One good example is Google’s Firebase Cloud Messaging(FCM) API used by Android. It requires sensitive scope but is very commonly used in Android apps with messaging to provide accurate push notifications. If you use the same Google app for both Android and Web applications, you’ll need to request this sensitive scope from Web users who won’t need FCM.
If you’re only triggering one API that requires sensitive/restrictive scopes, it’s worth considering if there’s an alternative to using this API. Having access to too much user’s information that the app doesn’t need is a liability.
Google has a help doc that details the prep work you need to apply for different levels of docs.
Go through the OAuth Consent Screen application in Google Developer Console
This is required for any app that wants to do any more than a simple login. Including using your own logo on the login screen.
Do an audit of all the scopes you need to use for your app.
At the time of submitting an application of your OAuth consent screen, you should have a working prototype of all the Google APIs you’re using, especially the ones with sensitive/restrictive scopes.
For sensitive/restrictive scopes, you’ll need to record a video of how your API is used, and upload it on YouTube. It’s best to do this at the time of application. Provide as much information as possible. It takes a couple of weeks for Google to go through your application. If Google asks for videos, it takes another couple of weeks to review it. Make sure you have a video for all the API calls at the time you submit your application.
At this time, you’ll also need your privacy notice and terms of service, since changing that triggers another application.
After submitting the application, sit back and wait. If you’ve filled out the application to the best of your knowledge and have videos for how all the APIs are being used, you should get some good news in a couple of weeks!
One thought on “Google Login in a Post GDPR/CCPA World”