In this guide we will guide you on how to fix you can’t sign in to this app because it doesn’t comply with Google’s OAuth 2.0 policy. So if you are surfing the internet since hours to get past the situation then you can rely on this blog. So without any further delay let’s get started. But before that lets discuss about Google’s OAuth 2.0 policy.

What is OAuth?

The OAuth (Open Authorization) protocol was developed by the Internet Engineering Task Force and enables safe delegated access. Its lets an app access a resource that is controlled by someone else (end User). This kind of access needs Tokens, which represent delegated right of access. That’s why applications get access without impersonating the user who controls the resource.

Here in this blog we have tried to provide some steps to comply with Google’s OAuth 2.0 Policies. So that you can follow guidelines to come into compliance with the most common developer problems encountered while preparing your app for production. It will help you to reach the largest possible audience with limited errors.

Use Separate Projects for Testing and Production

Google OAuth policies needs separate projects for testing and production. Some of the policies and requirements are only applied to production apps. So you might need to make and configure a separate project that includes OAuth clients that corresponds to production version of your app available to all the Google Accounts.

Google OAuth clients are used in production and help in providing predictable, more stable as well as secure data collection & storage environment than same OAuth clients that test or debug the same app. Your production project can submit for the verification and therefore be subject to additional requirements for specific API scopes, which probably include third party security assessments.

Step 1: Navigate to Google API Console , tap Create Project, enter name and tap Create

Step 2: Then Review OAuth Clients under the project that may be linked with your testing tier. If applicable, make similar OAuth clients for the production clients in the production project.

Step 3: Then Enable any APIs in use by your clients

Step 4: After that Review your OAuth Consent Screen configuration under the new project.

Google OAuth clients that are used in production must not have test environments, redirect URIs, or Java Script origins available to only you or your development team, we have enlisted some examples:

1. The test servers of the individual developers
2. Test or pre-release versions of the app

Maintain a list of relevant contacts for Project

Google, and the individual APIs that you enabled may need to contact you about the changes to its services or new configurations required of the project and its clients. Now Review the project’s IAM listings to ensure important people on your team have access to edit or view your project configuration. Note that these accounts might also get emails about the requisite changes to the project.

Role consists a set of permissions that allows user to perform particular actions on the project resources. Project Editors have permission for the actions which modify state, like the ability to make change to the project’s OAuth consent screen. The project owners who have all the editor permissions can add or delete accounts linked with the project, or delete the project. Project Owners can also offer context for why billing information might be set. The Project Owners can set up billing information for a project which uses paid APIs.

The Project Owners and the editors should be kept up-to-date. You can add several related accounts to the project to help. Make sure continued access to project and the related maintenance. Emails are received by those accounts that have notifications about the project or updates to our services. Google Cloud Organization administrators must make sure that an accessible contact is linked with every project in the organization. And if there is no up to date contact information for your project, then the chances are you will miss out on mandatory messages that demands your action.

Warning: Failure to act on timely notifications about the project may result in the loss of access to the Google APIs.

Points to Remember: One of the relevant contacts for project is the user support email configured for the OAuth consent screen. And if the users have troubles with your app, or Google Cloud Organization administrators have question on behalf of their users, and this email address is displayed so that they can get    in the contact.

Accurately Represent your Identity

You need to provide a genuine app name, optionally, a logo to show to the users. This brand information may exactly represent the identity of the application. App branding information is configured from OAuth Consent Screen Page.

And for the production apps, the brand information defined in the OAuth consent screen must be confirmed before it displays to users. The users might be more prone to grant access to the app after it finishes its brand verification. Basic application information, that includes app’s name, home page, terms of services and privacy policy are shown to the users on grant screen, and when they review their existing grants or to the Google Workspace Administrators which review app use by their organization

Google can revoke or suspend access to the Google API Service and the other Google Products and services for apps that fake their identity or try to mislead users.

Only Request Scopes that you want

During your application’s development, you might have used an example scope offered by API to make a proof-of –concept within your application in order to learn more about APIs features and functionality. These example scopes frequently request more information than final implementation of the app needs, as they offers wide-ranging coverage of all the possible actions for a specific API.

For example: The example scope may request read write & delete permissions while your application needs only read permissions, Request Relevant Permissions which are limited to critical information essential to implement the application.

Now review the reference documentation for API endpoint that your app calls and note the scopes that they needs to access the related data our app requires. Then review any authorization guides that API offers and describes the scopes in more detail in order to include the most common usage. Select the most minimal data access that your application requires to power the associated features.

Submit Production apps that use Sensitive or limited scopes for verification

Well certain scopes are classified as “Sensitive” or “Restricted” and cannot be used in production apps without review. You need to enter all scopes that your production app uses in its OAuth Consent Screen Configuration. Note that if your production app uses sensitive or limited scopes, you should submit your use of scopes for the verification before you include scopes in an authorization request.

Only Use Domains you own

The Google’s OAuth consent screen verification process needs verification of all domains related with the project’s home page, privacy policy, terms of service, authorized redirect URIs, or Authorized Java Script origins. Then review the list of domains in use by your app and summarized in Authorized domains section of OAuth consent screen editor and then recognize any domain that you don’t own & would therefore be unable to verify. In order to verify ownership of the project’s authorized domains, then use Google search Console. After that use Google Account that is related with the API Console Project as an Owner or an Editor.

And if your project uses a service provider with a regular, shared domain then we recommend enable configurations that may allow use of your own domain. Some providers offer to map their services to subdomain of a domain you already own.

Use Secure redirect URIs and JavaScript Origins

OAuth 2.0 clients for web pages must secure their data that is using HTTPS redirect URIs & JavaScript origins, not plain HTTP. Google can reject OAuth requests that don’t initiate from or resolve to a secure content.

Now consider which of the third party applications & scripts might have access to the tokens and the other user credentials that return to that page. Now limit access to the sensitive data will redirect URI locations that are restricted to verifying and storing token data.

Next Steps

Once you are ensured that your app compiles with OAuth 2.0 policies on the page then see Submit for brand verification for details about verification process.

Conclusion

That’s all about you can’t sign in to this app because it doesn’t comply with Google’s OAuth 2.0 policy. Hope you liked the blog. Thanks for Reading.