Entrevista de Ingeniería de Datos: ¿Cómo diseñaría conexiones OAuth seguras para PostgreSQL 18?

Consigna y contexto

Su equipo está actualizando una plataforma analítica multi-tenant a PostgreSQL 18 y desea que las aplicaciones se conecten con tokens de portador (bearer tokens) OAuth 2.0 en lugar de contraseñas de larga duración. Explique el límite de confianza de OAuth en PostgreSQL 18, el protocolo de enlace (handshake) de la conexión, el mapeo de roles y el plan de despliegue. Señale los puntos donde la autorización podría expandirse accidentalmente o donde un emisor (issuer) podría confundirse.

Qué evalúa el entrevistador

• Si distingue entre el cliente OAuth, el servidor de autorización, el servidor de recursos y el rol de base de datos.
• Si puede conectar pg_hba.conf, validadores, scopes, mapas y configuraciones de libpq en un único flujo de datos.
• Si reconoce los riesgos vinculados al descubrimiento, coincidencia exacta del emisor, TLS y tiempo de vida de los tokens.
• Si puede proponer una migración reversible en lugar de limitarse a decir “reemplazar contraseñas por tokens”.

Preguntas para clarificar

1. ¿Los emisores de llamadas son personas, servicios de backend o ambos? El tipo de entidad principal afecta si se trata de clientes públicos o confidenciales.
2. ¿Cada tenant se asigna a un rol de base de datos independiente? ¿Puede un token representar múltiples roles?
3. ¿El proveedor expone un documento de descubrimiento estándar y un validador de bearer tokens?
4. ¿Pueden los clientes heredados seguir usando SCRAM y de cuánto tiempo es la ventana de auditoría y reversión (rollback)?

Respuesta en 30 segundos

Trataría a PostgreSQL como el servidor de recursos, a libpq/psql como el cliente OAuth y al sistema de identidad externo como el servidor de autorización; la base de datos no emite tokens. El servidor habilita oauth en pg_hba.conf con un emisor exacto, scopes y validador, utilizando map cuando las identidades externas deben asignarse a roles de la base de datos. El cliente utiliza el descubrimiento y presenta un bearer token; el validador verifica la firma, el emisor, la audiencia, la expiración y los scopes. Mantendría SCRAM durante un despliegue progresivo por tenants, mediría los motivos de rechazo y eliminaría la regla de OAuth para revertir los cambios.

Análisis detallado

1. Definir el límite de confianza

PostgreSQL 18 agrega un método de autenticación OAuth, no un servidor de autorización. El proveedor autoriza a los usuarios y emite tokens; PostgreSQL valida un token y decide si una conexión puede asumir un rol de base de datos. Tratar la base de datos como una interfaz de inicio de sesión o almacenar tokens de actualización (refresh tokens) en ella ampliaría indebidamente su responsabilidad.

2. Configurar las reglas del servidor

Agregue una regla oauth en pg_hba.conf para la red y la base de datos de destino, con issuer, scope, el parámetro opcional validator y el parámetro opcional map. El emisor debe coincidir carácter por carácter con el documento de descubrimiento. Si hay varios validadores instalados, seleccione uno explícitamente. Coloque la regla antes de las reglas de contraseñas generales para que la solicitud no pase por alto a un método no deseado.

3. Gestionar el descubrimiento y el handshake

libpq utiliza oauth_issuer para recuperar metadatos de descubrimiento y luego obtiene un token según lo requiere el servidor. El emisor del cliente debe ser igual al emisor configurado en HBA. PostgreSQL documenta esta comparación exacta como una defensa contra ataques de confusión (mix-up attacks). Nunca incluya bearer tokens en logs de conexión, argumentos de procesos o configuraciones persistentes.

4. Validar tokens y roles

Un validador debe verificar la firma, el emisor, el tiempo de vida, la audiencia y los scopes requeridos, devolviendo luego una identidad externa auditable. Sin map, el nombre de usuario validado debe coincidir exactamente con el rol solicitado. Para entornos multi-tenant, utilice un mapa explícito de privilegio mínimo con denegación por defecto. delegate_ident_mapping elude el mapeo estándar de pg_ident.conf y solo debe utilizarse cuando el propio validador realiza una autorización completa del rol.

5. Despliegue y reversión

Verifique el descubrimiento, TLS, los scopes y el comportamiento con tokens expirados fuera de producción. Agregue reglas OAuth en HBA para un grupo reducido de servicios mientras mantiene SCRAM. Mida por separado los éxitos, expiraciones, discrepancias de emisor y rechazos de mapeo. Expanda el despliegue una vez que los connection pools, los trabajos batch y los scripts operativos puedan renovar tokens. Realice la reversión eliminando la regla de OAuth o restaurando SCRAM mientras conserva las credenciales antiguas hasta que todos los pools hayan migrado.

Ejemplo de respuesta de alta calidad

Plantearía cuatro actores: el servicio es el cliente, la plataforma de identidad es el servidor de autorización, PostgreSQL es el servidor de recursos y un rol de base de datos es el objetivo de autorización local. El método HBA oauth define el emisor, los scopes y el validador, y mapea la identidad del token a un rol del tenant. Evitaría delegate_ident_mapping a menos que el validador compruebe por sí mismo la autorización del rol. Los clientes utilizarían el descubrimiento con oauth_issuer, forzarían TLS y mantendrían los tokens fuera de los logs. Durante un despliegue progresivo por tenants, SCRAM permanece disponible, mientras que los paneles de monitoreo diferencian los fallos por emisor, scopes, expiración y mapeo. La eliminación de la regla OAuth proporciona una reversión inmediata. Esto aprovecha la capacidad nativa de PostgreSQL 18 manteniendo separados la emisión de tokens, la autorización de base de datos y el control de la migración.

Errores comunes

• Afirmar que PostgreSQL emite tokens OAuth, confundiendo el servidor de recursos con el de autorización.
• Verificar únicamente la firma JWT omitiendo las comprobaciones de emisor, audiencia, expiración o scopes.
• Asumir que un emisor en el mismo dominio es suficiente e ignorar la coincidencia exacta de descubrimiento.
• Habilitar delegate_ident_mapping sin explicar la autorización de roles por parte del validador.
• Escribir bearer tokens en logs de conexión, trazas o variables de entorno persistentes.
• Eliminar SCRAM en un solo paso, dejando a los pools y trabajos batch sin un camino de reversión.

Preguntas de seguimiento y respuestas

¿Por qué debe coincidir exactamente el emisor?

El cliente construye una URL de descubrimiento a partir del emisor y compara el emisor devuelto con su configuración. Variaciones en mayúsculas/minúsculas, formato y rutas pueden hacer fallar la conexión; la comparación estricta también evita que un cliente sea redirigido a un servidor de autorización no deseado.

¿Cómo se elige el rol sin un mapa?

El nombre de usuario devuelto por el validador debe coincidir exactamente con el rol solicitado por la conexión. Las implementaciones multi-tenant suelen requerir un mapa explícito con comportamiento de denegación por defecto para que una identidad no reciba un rol privilegiado automáticamente.

¿Cómo se preserva la disponibilidad cuando OAuth falla?

Mantenga credenciales SCRAM de corta duración para reversión y migre los connection pools gradualmente. Monitoree las fallas por tipo, luego elimine la regla OAuth de HBA y restaure la regla anterior si el descubrimiento, los scopes o el comportamiento del validador presentan problemas.