This page explains how to share an OAuth client with another app within your organization.
Sharing OAuth clients between projects removes the need to manually create a new OAuth client for every app under your organization. After manually creating one OAuth client, you can programmatically assign it to multiple apps.
OAuth client sharing is also used to share a default OAuth client with agents you want to be able to enable Cloud Identity-Aware Proxy (Cloud IAP) but not have access to the Credentials page.
Note that mobile apps can't authenticate with OAuth clients from a different project.
Before you begin
Follow one of the guides below to enable Cloud IAP for an app and create an OAuth client.
- Enabling Cloud IAP for Compute Engine (Compute Engine)
- Enabling Cloud IAP for Google Kubernetes Engine (GKE)
Note that client sharing with App Engine isn't currently supported.
Assigning a shared client to Compute Engine apps
- Go to the Instance groups page to make sure your instances are in an instance group.
- Define backend services.
- Set up load balancing.
- Using the gcloud command-line tool, run
gcloud auth login.
- Follow the URL that appears to sign in.
- After you sign in, copy the verification code that appears and paste it in the command line.
gcloud config set project PROJECT_IDfor the project for which you want to enable Cloud IAP.
To enable Cloud IAP, use your shared client's ID and secret from the Credentials page and run the following command:
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --global --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET
Assigning a shared client to GKE apps
Follow the steps to configure your app's BackendConfig file, instead using your shared client's ID and secret when running the following command:
kubectl create secret generic my-secret --from-literal=client_id=CLIENT_ID \ --from-literal=client_secret=CLIENT_SECRET
While sharing a client between your apps is convenient, there are risks. This section outlines potential risks when sharing clients and how to mitigate them.
Single point of failure
Using one OAuth client for many apps creates a single point of failure. If a client is deleted or modified incorrectly, every app that uses that client is impacted.
To mitigate this, only share clients when fulfilling an important use case for shared clients.
Client secret leaks
Sharing a client requires sharing your client secret with people and scripts. This increases the risk of your client secret leaking. Cloud IAP can't differentiate between tokens created from your app and tokens created from a leaked client secret.
To mitigate this risk, protect client secrets like a password. Limit sharing them and never store them as plaintext.
Impersonation of authorized users
If your client secret is leaked, a malicious app can set the Cloud IAP authentication browser cookie on its domain to impersonate an authorized user. With this cookie, Cloud IAP authenticates the impersonated user for all apps that share the leaked client secret.
To mitigate this risk, avoid sharing clients between resources that also share authorized users. Set per-resource permissions to ensure that even if an impersonated user is authenticated, Cloud IAP won't authorize access.
User identity collection
If your client secret is leaked, a malicious app can use your client ID to collect the identities of your app's users. This is triggered when your users visit the malicious app.
When a user accesses a Cloud IAP-protected app for the first time, they're asked to share their identity with the app. This gives users control over their personal information. When a user consents to share their identity, the Google login system records that consent. Cloud IAP won't re-prompt the user on subsequent requests from any client ID in the same project.
Any user who has consented to share their identity with your app, and who visits the malicious app, will immediately have their identity shared without their consent.