Registering with Google

If you plan to integrate with the Google Assistant, see Actions on Google Console.

Otherwise, before you add OAuth 2.0 authorization to your service, prepare the following information and contact your developer relations or business development representative:

  • Authorization endpoint URL. This is the URL for the authorization endpoint which you host and that Google makes calls to. Traffic should be accepted over HTTPS only. For example, https://myservice.example.com/auth. Oftentimes an existing sign-in page can be adapted to serve as the authorization endpoint.

    The redirect_uri sent as a parameter to your authorization endpoint will have the following form: 

    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID

    Theredirect_uri should be allowlisted for the client_id you assign to Google.

  • Token endpoint URL. This is the URL for the token endpoint which you host and Google makes calls to. Traffic should be accepted over HTTPS and only from other known services (such as Google's). For example, https://oauth2.example.com/token. The authorization and token endpoints may be hosted on different domains.

  • Optional token revocation endpoint URL. This is the URL for the revocation endpoint which you host and Google makes calls to. Traffic should be accepted over HTTPS and only from other known services (such as Google's). For example, https://oauth2.example.com/revoke. Your authorization, token and revocation endpoints may be hosted on different domains.

  • Optional Cross-Account Protection (RISC) URL. This is a URL you host and Google makes calls to. You may chose the value.

  • Client ID and client secret for Google. You must assign Google a client ID, which is used in OAuth 2.0 requests to identify the request's origin, and a client secret, which is used to prevent request forgery. The Google client ID and client secret can be any URL-safe string values of your choice. You must ensure that the client secret is visible to only Google and your service.

  • Optional scope strings. Depending on how much and what kind of user data your API makes available, you might want to define scopes that represent different categories of user data. By doing so, parties can ask permission from your users to access only certain kinds of data, and restrict the data available to clients to only the authorized scopes. In particular, if your service makes more data available than necessary for integration with Google, you might use scopes to grant access to only some of the data.

  • Your Google API Project ID