Esta página se ha traducido con Cloud Translation API.

Cómo compartir clientes de OAuth

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

Información general

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

Al configurar IAP, puedes usar uno de estos dos tipos de cliente de OAuth:

Cliente de OAuth gestionado por Google: IAP lo usa automáticamente de forma predeterminada. Esta opción integrada no requiere que se cree un cliente manualmente, pero tiene dos limitaciones importantes:
- Solo permite el acceso a los usuarios de tu organización (usuarios internos)
- Muestra la Google Cloud marca en la pantalla de consentimiento en lugar de la marca de tu organización
Cliente de OAuth personalizado: lo creas y gestionas tú. Esta opción:
- Se puede compartir entre varias aplicaciones
- Permite personalizar la marca en la pantalla de consentimiento
- Admite el acceso de usuarios externos (ajenos a tu organización)

Cuando creas un cliente de OAuth personalizado, puedes usarlo con una sola aplicación o compartirlo entre varias. Compartir un cliente de OAuth personalizado ofrece varias ventajas:

Reduce la sobrecarga administrativa de gestionar 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 a través del navegador) a las aplicaciones protegidas por IAP.

Para obtener información sobre cómo crear clientes de OAuth, consulta Crear clientes de OAuth para IAP. Para obtener más información sobre los clientes de OAuth gestionados por Google, consulta Personalizar una configuración de OAuth para habilitar IAP.

Antes de empezar

Para crear un cliente de OAuth, sigue los pasos que se indican en el artículo Crear un cliente de OAuth. También puedes usar un cliente de OAuth que ya tengas.

Acceso programático

Configura clientes de OAuth para el acceso programático y permite que las aplicaciones que no sean navegadores se autentiquen con tus recursos protegidos por IAP. Esto permite que las secuencias de comandos, los trabajos automatizados y los servicios backend accedan de forma segura a tus aplicaciones protegidas sin que los usuarios tengan que iniciar sesión de forma interactiva.

Puedes aplicar estos ajustes de autenticación en cualquier nivel de tu jerarquía de recursos: organización, carpeta o proyecto.

Para ver los pasos de implementación, consulta la guía de autenticación programática y la documentación sobre la gestión de ajustes de las compras en la aplicación.

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 los ajustes 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]

Ejemplos de comandos:

# 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

Donde:

SETTINGS_FILENAME: el archivo YAML que has preparado.
ORGANIZATION: ID de la organización
FOLDER: ID de la carpeta
PROJECT: el ID del proyecto
RESOURCE_TYPE: el tipo de recurso de IAP (app-engine, iap_web, compute, organization o folder)
SERVICE: nombre del servicio (opcional para los tipos de recursos compute o app-engine)
VERSION: el nombre de la versión (no aplicable 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"
```
Donde:
- ORGANIZATION: ID de la organización
- FOLDER: ID de la carpeta
- PROJECT: el ID del proyecto
- RESOURCE_TYPE: el tipo de recurso de IAP (app-engine, iap_web, compute, organization o folder)
- SERVICE: nombre del servicio (opcional para los tipos de recursos compute o app-engine)
- VERSION: el nombre de la versión (no aplicable a compute, opcional para app-engine)

Después de la configuración, inicia sesión en la aplicación con cualquiera de los IDs de cliente de OAuth que hayas configurado. Consulta Autenticación mediante programación para obtener más información.

Acceso con navegador

Para habilitar la compra en la aplicación para que use tu ID de cliente y tu secreto a través de laGoogle Cloud consola, sigue estas instrucciones:

Riesgos

Aunque compartir un cliente entre tus aplicaciones es práctico, conlleva riesgos. En esta sección se describen los riesgos potenciales de compartir clientes y cómo mitigarlos.

Punto único de fallo

Si se usa un cliente de OAuth para muchas aplicaciones, se crea un único punto de dependencia. Si un cliente se elimina o se modifica de forma incorrecta, todas las aplicaciones que lo usen se verán afectadas. Los clientes de OAuth eliminados se pueden restaurar en un plazo de 30 días.

Para gestionar este riesgo operativo de forma eficaz, sigue estos pasos:

Implementa controles de acceso adecuados para evitar cambios o eliminaciones accidentales
Restringir el acceso a los clientes de OAuth mediante permisos de clientauthconfig.clients.*
Usa Google Cloud Registros de auditoría para monitorizar las actividades administrativas relacionadas con los clientes de OAuth

Se trata principalmente de un riesgo operativo, no de un riesgo de seguridad. Si se implementan controles de acceso y una monitorización adecuados, las ventajas de gestión y la comodidad de los clientes de OAuth compartidos suelen ser mayores que este aspecto.

Filtraciones de secretos de cliente

Para compartir un cliente, debes compartir su secreto con personas y secuencias de comandos. De esta forma, aumenta el riesgo de que se filtre el secreto de cliente. Las compras en aplicaciones no pueden distinguir entre los tokens creados desde tu aplicación y los tokens creados a partir de un secreto de cliente filtrado.

Para mitigar este riesgo, sigue estos pasos:

Protege los secretos de cliente, como las contraseñas, y nunca los almacenes como texto sin formato.
Implementar la gestión segura de credenciales con Secret Manager
Monitorizar el acceso a los recursos de IAP con Cloud Audit Logging
Un secreto de cliente filtrado solo afecta a la autenticación, no a la autorización para acceder a los recursos. Si sospechas que se ha filtrado tu secreto, cámbialo inmediatamente.

Para acceder de forma programática a recursos protegidos por IAP, te recomendamos que uses la autenticación JWT de cuentas de servicio en lugar de compartir secretos de cliente de OAuth con usuarios concretos. Este enfoque proporciona un mejor aislamiento de seguridad y, al mismo tiempo, mantiene las ventajas de un cliente de OAuth compartido para tus aplicaciones.

Consideraciones sobre el ámbito de los permisos

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

OAuth solo se usa para la autenticación (verificación de la identidad) en IAP. La autorización (acceso a recursos) se gestiona por separado mediante políticas de IAM.
Aunque las credenciales de autenticación se vean comprometidas, un atacante seguiría necesitando los permisos de gestión de identidades y accesos adecuados para acceder a los recursos protegidos.
Restringir el cliente a los ámbitos openid y email necesarios ayuda a limitar el posible impacto en la seguridad

Cómo compartir clientes de OAuth Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.