Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

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 con 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 configuras IAP, puedes usar uno de los dos tipos de clientes de OAuth:

Cliente de OAuth administrado por Google: IAP lo usa automáticamente de forma predeterminada. Esta opción integrada no requiere la creación manual de clientes, pero tiene dos limitaciones clave:
- Solo permite el acceso a los usuarios de tu organización (usuarios internos).
- Muestra Google Cloud la marca en la pantalla de consentimiento en lugar de la marca de tu organización.
Cliente de OAuth personalizado: Tú mismo lo creas y administras. Esta opción:
- Se puede compartir en varias aplicaciones.
- Permite la personalización de 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 proporciona 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 (sin 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 IAP.

Antes de comenzar

Para crear un cliente de OAuth nuevo, completa los pasos 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 para permitir 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 acceda de forma interactiva.

Puedes aplicar esta 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 de 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 gcloud iap settings set comando:

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 organización.
FOLDER: Es el ID de la carpeta.
PROJECT: Es el ID del proyecto.
RESOURCE_TYPE: Es el tipo de recurso de IAP (app-engine, iap_web, compute, organization o folder)
SERVICE: Es el nombre del servicio (opcional para compute o app-engine tipos de recursos).
VERSION: Es el nombre de la versión (no aplicable para 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 organización.
- FOLDER: Es el ID de la carpeta.
- PROJECT: Es el ID del proyecto.
- RESOURCE_TYPE: Es el tipo de recurso de IAP (app-engine, iap_web, compute, organization o folder)
- SERVICE: Es el nombre del servicio (opcional para compute o app-engine tipos de recursos).
- VERSION: Es el nombre de la versión (no aplicable para 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 Google Cloud consola, completa las siguientes instrucciones:

Riesgos

Si bien compartir un cliente entre tus aplicaciones es conveniente, 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 varias aplicaciones crea un punto único de dependencia. Si se borra o modifica un cliente de forma incorrecta, se ve afectada cada aplicación que lo usa. 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 borrados accidentales.
Restringe el acceso a los clientes de OAuth con los permisos clientauthconfig.clients.*.
Usa los Google Cloud registros de auditoría para hacer un seguimiento de las actividades administrativas que involucran a los clientes de OAuth.

Este es principalmente un riesgo operativo en lugar de 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 el secreto del cliente. IAP no puede diferenciar entre los tokens creados a partir de tu aplicación y los tokens creados a partir de un secreto del cliente filtrado.

Para mitigar este riesgo, haz lo siguiente:

Protege los secretos del cliente como 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 Registros de auditoría de Cloud.
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 JWT de la cuenta de servicio en lugar de compartir los secretos del cliente 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 del permiso

Cuando se comparten clientes de OAuth, todas las aplicaciones usan los mismos alcances de permisos. Para IAP, openid y email son los únicos alcances obligatorios. Esta consideración por sí sola no es 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 los recursos) se maneja por separado a través de las políticas de IAM
Incluso si las credenciales de autenticación se ven comprometidas, un atacante aún necesitaría los permisos de IAM adecuados para acceder a los recursos protegidos.
Restringir el cliente solo a los alcances openid y email obligatorios 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.