Your OAuth client is the credential which your application uses when making calls to Google OAuth 2.0 endpoint to receive an access token or ID token. After creating your OAuth client, you will receive a client ID and sometimes, a client secret.
Think of your client ID like your app's unique username when it needs to request an access token or ID token from Google's OAuth 2.0 endpoint. This ID helps Google identify your app and ensure that only authorized applications can access user data.
Client ID and Client Secret
Similar to how you would use a username and password to log to online services, many applications use a client ID paired with a client secret. The client secret adds an extra layer of security, acting like your app's password.
Applications are categorized as either public or private clients:
- Private Clients: These apps, like web server applications, can securely store the client secret because they run on servers you control.
- Public Clients: Native apps or JavaScript-based apps fall under this category. They cannot securely store secrets, as they reside on user devices and as such do not use client secrets.
To create an OAuth 2.0 client ID in the console:
- Navigate to the Google Auth Platform Clients page.
- You will be prompted to create a project if you do not have one selected.
- You will be prompted to register your application to use Google Auth if you are yet to do so. This is required before creating a client.
- Click CREATE CLIENT
- Select the appropriate application type for your application and enter any additional information required. Application types are described in more detail in the following sections.
- Fill out the required information for the select client type and click the CREATE button to create the client.
Note : Your application’s client secret will only be shown after you create the client. Store this information in a secure place because it will not be visible or accessible again. If the client secret is lost, you will need to create a new one using the client secret rotation feature.
Application types
A web application is accessed by web browsers over a network.
Authorized JavaScript origins
Applications that use client-side JavaScript to access Google APIs must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests.
Specified origins must adhere to the following rules :
- JavaScript origins must use the HTTPS scheme, not plain HTTP. Localhost URIs (including localhost IP address URIs) are exempt from this rule.
- Hosts cannot be raw IP addresses. Localhost IP addresses are exempted from this rule.
- If you use a port other than 80, you must specify it. For example: https://example.com:8080
- Host TLDs (Top Level Domains) must belong to the public suffix list.
- Host domains cannot be “googleusercontent.com”.
- JavaScript origins cannot contain URL shortener domains (e.g. goo.gl) unless the app owns the domain.
- JavaScript origins cannot contain the userinfo subcomponent.
- JavaScript origins cannot contain the path component.
- JavaScript origins cannot contain the query component.
- JavaScript origins cannot contain the fragment component.
- JavaScript origins cannot contain certain characters including:
- Wildcard characters ('*')
- Non-printable ASCII characters
- Invalid percent encodings (any percent encoding that does not follow URL-encoding form of a percent sign followed by two hexadecimal digits)
- Null characters (an encoded NULL character, e.g., %00, %C0%80)
If you send a request to a Google OAuth 2.0 endpoint from an unregistered JavaScript origin, you will receive an origin_mismatch error.
Applications that access Google APIs from a server (often using languages and frameworks like Node.js, Java, .NET, and Python) must specify authorized redirect URIs. The redirect URIs are the endpoints of your application server to which the OAuth 2.0 server can send responses. Users are redirected to this path after they have authenticated with Google.
Redirect URIs must adhere to the following rules :
- Redirect URIs must use the HTTPS scheme, not plain HTTP. Localhost URIs (including localhost IP address URIs) are exempt from this rule.
- Hosts cannot be raw IP addresses. Localhost IP addresses are exempted from this rule.
- Host TLDs (Top Level Domains) must belong to the public suffix list.
- Redirect URIs cannot contain URL shortener domains (e.g. goo.gl) unless the app owns the domain. Furthermore, if an app that owns a shortener domain chooses to redirect to that domain, that redirect URI must either contain “/google-callback/” in its path or end with “/google-callback”.
- Redirect URIs cannot contain the userinfo subcomponent.
- Redirect URIs cannot contain a path traversal (also called directory backtracking), which is represented by an “/..” or “\..” or their URL encoding.
- Redirect URIs cannot contain open redirects.
- Redirect URIs cannot contain the fragment component.
- Redirect URIs cannot contain certain characters including:
- Wildcard characters ('*')
- Non-printable ASCII characters
- Invalid percent encodings (any percent encoding that does not follow URL-encoding form of a percent sign followed by two hexadecimal digits)
- Null characters (an encoded NULL character, e.g., %00, %C0%80)
If the redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID, you will receive a redirect_uri_mismatch error.
Note: It may take 5 minutes to a few hours for changes made to these settings to take effect
Delete OAuth Clients
To delete a client ID, go to the Clients page, check the box next to the ID you want to delete, and then click the DELETE button.
Before deleting a Client ID, ensure to check the ID is not in use by monitoring your traffic in the overview page.
You can restore deleted clients within 30 days of the deletion. To restore a recently deleted client, navigate to the Deleted credentials page to find a list of clients you recently deleted and click the RESTORE button for the client you want to restore.
Any client deleted over 30 days ago cannot be restored and is permanently deleted.
Rotating your clients secrets
Client secrets or credentials should be treated with extreme care as described in the OAuth 2.0 policies, because they allow anyone who has them to use your app's identity to gain access to user information. With the client secret rotation feature, you can add a new secret to your OAuth client configuration, migrate to the new secret while the old secret is still usable, and disable the old secret afterwards. This is useful when the client secret has been inadvertently disclosed or leaked. This also ensures good security practices by occasionally rotating your secrets without causing downtime of your app. In addition, Google started to issue more secure client secrets recommended by RFC 6749 in 2021. While apps that were created earlier are able to continue using the old secrets, we recommend that you migrate to the new secret with this rotation feature.
To rotate your client secret, please follow the following steps: