Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Cómo compartir clientes de OAuth

En esta página, se explica cómo compartir un cliente de OAuth con otra aplicación dentro de tu organización.

Descripción general

Compartir clientes de OAuth entre proyectos significa usar un solo cliente de OAuth personalizado para varias aplicaciones protegidas por Identity-Aware Proxy (IAP) en lugar de crear un cliente de OAuth nuevo para cada aplicación. Este enfoque simplifica la administración, en especial para las organizaciones con muchas aplicaciones.

Cuando configures IAP, puedes usar uno de los siguientes tipos de clientes de OAuth:

Cliente de OAuth administrado por Google: IAP usa automáticamente este cliente de forma predeterminada. Esta opción integrada no requiere la creación manual del cliente, pero tiene dos limitaciones clave:
- Solo permite el acceso a los usuarios de tu organización (usuarios internos)
- Muestra Google Cloud el desarrollo de la marca en la pantalla de consentimiento en lugar del desarrollo de la marca de tu organización.
Cliente de OAuth personalizado: Tú mismo lo creas y administras. Esta opción:
- Se puede compartir entre varias aplicaciones
- Permite personalizar la marca en la pantalla de consentimiento
- Admite el acceso para usuarios externos (fuera de tu organización)

Cuando creas un cliente de OAuth personalizado, tienes la flexibilidad de usarlo con una sola aplicación o compartirlo en varias aplicaciones. Compartir un cliente de OAuth personalizado ofrece varios beneficios:

Reduce la sobrecarga administrativa de la administración de varios clientes
Simplifica la habilitación de IAP para los miembros del equipo que no deberían tener acceso a la página Credenciales
Facilita el acceso programático (no basado en navegador) a las aplicaciones protegidas por IAP

Para obtener información sobre cómo crear clientes de OAuth, consulta Crea clientes de OAuth para IAP. Para obtener detalles sobre los clientes de OAuth administrados por Google, consulta Personaliza una configuración de OAuth para habilitar las IAP.

Antes de comenzar

Crea un cliente de OAuth nuevo siguiendo los pasos que se indican en Creación de clientes de OAuth o usa un cliente de OAuth existente.

Acceso programático

Configura clientes de OAuth para el acceso programático y permite que las aplicaciones que no son de navegador se autentiquen con tus recursos protegidos por IAP. Esto permite que las secuencias de comandos, los trabajos automatizados y los servicios de backend accedan de forma segura a tus aplicaciones protegidas sin que el usuario tenga que acceder de forma interactiva.

Puedes aplicar estos parámetros de configuración de autenticación en cualquier nivel de la jerarquía de recursos: organización, carpeta o proyecto.

Para conocer los pasos de implementación, consulta la guía de autenticación programática y la documentación sobre la administración de la configuración de IAP.

gcloud

Prepara un archivo de configuración con tus IDs de cliente de OAuth:

cat << EOF > SETTINGS_FILENAME
  access_settings:
    oauth_settings:
      programmatic_clients: [clientId1, clientId2, ..]
EOF

Aplica la configuración con el comando gcloud iap settings set:

gcloud iap settings set SETTINGS_FILENAME \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

Comandos de ejemplo:

# Organization level
gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION

# Folder level
gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER

# Project level (web resources)
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=iap_web

# App Engine service in a project
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=app-engine \
  --service=SERVICE

Aquí:

SETTINGS_FILENAME: Es el archivo YAML que preparaste.
ORGANIZATION: Es el ID de la organización.
FOLDER: El ID de la carpeta
PROJECT: el ID del proyecto
RESOURCE_TYPE: Es el tipo de recurso de IAP (app-engine, iap_web, compute, organization o folder).
SERVICE: El nombre del servicio (opcional para los tipos de recursos compute o app-engine)
VERSION: El nombre de la versión (no se aplica a compute, opcional para app-engine)

API

Prepara un archivo JSON de configuración:

cat << EOF > iap_settings.json
{
  "access_settings": {
    "oauth_settings": {
      programmatic_clients: [clientId1, clientId2, ..]
    }
  }
}
EOF

Obtén el nombre del recurso:

gcloud iap settings get \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

Actualiza la configuración con el nombre del recurso:
```
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"
```
Aquí:
- ORGANIZATION: Es el ID de la organización.
- FOLDER: El ID de la carpeta
- PROJECT: el ID del proyecto
- RESOURCE_TYPE: Es el tipo de recurso de IAP (app-engine, iap_web, compute, organization o folder).
- SERVICE: El nombre del servicio (opcional para los tipos de recursos compute o app-engine)
- VERSION: El nombre de la versión (no se aplica a compute, opcional para app-engine)

Después de la configuración, accede a la aplicación con cualquiera de los IDs de cliente de OAuth que configuraste. Consulta Autenticación programática para obtener más información.

Acceso del navegador

Para habilitar IAP para que use tu ID y secreto de cliente a través de la consola deGoogle Cloud , completa las siguientes instrucciones:

Riesgos

Si bien es conveniente compartir un cliente entre tus aplicaciones, existen riesgos. En esta sección, se describen los posibles riesgos de compartir clientes y cómo mitigarlos.

Punto único de fallo

El uso de un cliente de OAuth para muchas aplicaciones crea un único punto de dependencia. Si un cliente se borra o se modifica de forma incorrecta, todas las aplicaciones que usan ese cliente se verán afectadas. Los clientes de OAuth borrados se pueden restablecer en un plazo de 30 días.

Para administrar este riesgo operativo de manera eficaz, haz lo siguiente:

Implementa controles de acceso adecuados para evitar cambios o eliminaciones accidentales
Restringe el acceso a los clientes de OAuth con permisos de clientauthconfig.clients.*
Usa los Google Cloud registros de auditoría para hacer un seguimiento de las actividades administrativas que involucran a clientes de OAuth.

Este es principalmente un riesgo operativo, no un riesgo de seguridad. Con los controles de acceso y la supervisión adecuados, los beneficios de conveniencia y administración de los clientes de OAuth compartidos suelen superar esta consideración.

Filtraciones de secretos del cliente

Para compartir un cliente, debes compartir el secreto del cliente con personas y secuencias de comandos. Esto aumenta el riesgo de que se filtre tu secreto del cliente. IAP no puede distinguir entre tokens creados a partir de tu aplicación y tokens creados a partir de un secreto del cliente filtrado.

Para mitigar este riesgo, haz lo siguiente:

Protege los secretos del cliente, como las contraseñas, y nunca los almacenes como texto sin formato.
Implementa la administración segura de credenciales con Secret Manager
Supervisa el acceso a tus recursos de IAP con Cloud Audit Logging
Un secreto del cliente filtrado solo afecta la autenticación, no la autorización para acceder a los recursos. Si sospechas que se filtró tu secreto, restablecerlo de inmediato.

Para el acceso programático a los recursos protegidos por IAP, considera usar la autenticación con JWT de cuentas de servicio en lugar de compartir secretos de clientes de OAuth con usuarios individuales. Este enfoque proporciona un mejor aislamiento de seguridad y, al mismo tiempo, mantiene los beneficios de un cliente de OAuth compartido para tus aplicaciones.

Consideraciones sobre el alcance de los permisos

Cuando se comparten clientes de OAuth, todas las aplicaciones usan los mismos permisos. En el caso de las IAP, openid y email son los únicos permisos obligatorios. Esta consideración por sí sola no representa un riesgo significativo, pero es importante comprender lo siguiente:

OAuth solo se usa para la autenticación (verificación de identidad) en IAP; la autorización (acceso a recursos) se controla por separado a través de políticas de IAM.
Incluso si se vulneran las credenciales de autenticación, un atacante necesitaría los permisos de IAM adecuados para acceder a los recursos protegidos.
Restringir el cliente solo a los permisos de openid y email necesarios ayuda a limitar el posible impacto en la seguridad.

Cómo compartir clientes de OAuth Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.