{"id":10845,"date":"2020-01-05T04:41:52","date_gmt":"2020-01-05T04:41:52","guid":{"rendered":"https:\/\/www.gmass.co\/blog\/?p=10845"},"modified":"2020-01-31T01:59:53","modified_gmt":"2020-01-31T01:59:53","slug":"five-annoying-issues-google-oauth-scope-verification","status":"publish","type":"post","link":"https:\/\/www.gmass.co\/blog\/five-annoying-issues-google-oauth-scope-verification\/","title":{"rendered":"Five annoying issues with Google’s OAuth Scope Verification"},"content":{"rendered":"

It’s 2020, when Google promised to shut off many third-party apps that weren’t verified by December 31, 2019. While I haven’t heard any reports of anyone being shut off yet, having been through Google’s OAuth verification process<\/a>, and having run some Unverified Apps, I’ve learned the ins and outs of the whole process. All of these insights I’ve concluded on my own, thanks to Google’s insufficient documentation.<\/p>\n

1. There’s no hierarchy to the API Scopes, and that’s just ridiculous<\/h3>\n

Let’s say you’ve been approved for the almighty https:\/\/mail.google.com<\/strong> Gmail API scope, which gives you full access to read, write, and delete data in a user’s Gmail account. Then later, you realize you don’t need this almighty scope \u2014 you determine you just need modify-only access<\/strong> to Gmail. You also want the benefit of a less scary warning for your user. You might think that you can just switch your OAuth code to use the less permissive scope, https:\/\/www.googleapis.com\/auth\/gmail.modify<\/strong>, and you’ll be good to go. That makes logical sense, after all.<\/em><\/p>\n

But you’ll be shocked to learn that you’ve just re-entered “Unverified App” territory.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

That’s right. Internally, Google doesn’t know that if you’ve been approved for the mail.google.com scope, which covers everything, you should also be approved for the “modify” scope, which grants a subset of permissions of the mail.google.com scope. There’s no hierarchy to the scopes as far as Google is concerned, which is absolutely ridiculous given that Google’s main business is to organize the world’s information. Funny that Google is so good at organizing trillions of web pages but is terrible at organizing a few hundred of its own API scopes.<\/p>\n

2. Where exactly do you designate the scopes you want to use?<\/h3>\n

The whole OAuth process might be confusing to you because you’ve likely noticed that there are three places to specify the API libraries you want access:<\/p>\n

    \n
  1. In the Cloud Console, under the API Library<\/strong> section<\/li>\n
  2. In the Cloud Console, under your specific OAuth consent screen<\/li>\n
  3. In your code where you hit the Google OAuth2 endpoint<\/li>\n<\/ol>\n

    So which list is most important? Do you have to specify the scopes in the Cloud Console consent screen settings for your code to request access to that scope for a user? No, you don’t.<\/em><\/p>\n

    Here’s an example. In the Cloud Console for my GMass app, here’s the list of Enabled APIs<\/strong>:<\/p>\n

    \"\"<\/a><\/p>\n

     <\/p>\n

    My OAuth client consent screen lists these scopes:<\/p>\n

    \"\"<\/a><\/p>\n

    In code, I can request access to a scope that’s not listed in either the Dashboard or my OAuth client page, and it might still work, depending on the scope that I add. For example, I can add the “https:\/\/www.googleapis.com\/auth\/genomics”<\/strong> scope, which has nothing to do with my project, and the user can still authenticate but IS presented with the Unverified App screen.<\/p>\n

    \r\n        private static readonly string[] GMass_Scopes = new[] {\r\n        "https:\/\/mail.google.com",\r\n        "https:\/\/www.googleapis.com\/auth\/userinfo.email",\r\n        "https:\/\/spreadsheets.google.com\/feeds",\r\n        "https:\/\/www.googleapis.com\/auth\/genomics"\r\n        };\r\n\r\n        public ActionResult Login(string redir = null, bool connect = false, string emailaddress = "", string source = "extension")\r\n        {\r\n            OAuthState state = new OAuthState\r\n            {\r\n                Connect = connect,\r\n                Redir = redir,\r\n                Source = source\r\n            };\r\n\r\n            UriBuilder uri = new UriBuilder();\r\n            uri.Scheme = "https:";\r\n            uri.Host = "accounts.google.com";\r\n            uri.Path = "\/o\/oauth2\/auth";\r\n\r\n            var qs = HttpUtility.ParseQueryString("");\r\n            if (emailaddress != "")\r\n            {\r\n                qs["login_hint"] = emailaddress;\r\n            }\r\n            qs["access_type"] = "offline";\r\n            qs["response_type"] = "code";\r\n            qs["approval_prompt"] = "force";\r\n            qs["client_id"] = OAuthHelper.ClientSecrets.ClientId;\r\n            qs["redirect_uri"] = "https:\/\/extension.gmass.co\/OAuth\/AuthCallback";\r\n            qs["scope"] = string.Join(" ", GMass_Scopes);\r\n            qs["state"] = JsonConvert.SerializeObject(state);\r\n            uri.Query = qs.ToString();\r\n\r\n            return Redirect(uri.ToString());\r\n        }\r\n<\/pre>\n
    But, if I add the “https:\/\/www.googleapis.com\/auth\/drive.file”<\/strong> scope, also which is not enabled in Cloud Console’s API Library<\/strong> and not listed as part of my OAuth consent screen<\/strong>, then the user sails right through when logging in, and does not see the Unverified App<\/strong> screen. The “genomics” API isn’t documented as sensitive or restricted, so this difference doesn’t really make sense.<\/p>\n
    The rules are as follows:<\/p>\n