OAuth 2.0 es un marco estándar de la industria, definido en la norma RFC 6749, para permitir que las aplicaciones de terceros obtengan acceso limitado a un recurso protegido. El soporte para el cliente OAuth debe habilitarse cuando se compila PostgreSQL; consulta la sección Chapter 17 para obtener más información.
Esta documentación utiliza la siguiente terminología al hablar del ecosistema OAuth:
El usuario o sistema propietario de los recursos protegidos y que puede conceder acceso a los mismos. Esta documentación también utiliza el término usuario final cuando el propietario del recurso es una persona. Cuando utilizas psql para conectarte a la base de datos empleando OAuth, tú eres el propietario del recurso/usuario final.
El sistema que accede a los recursos protegidos utilizando tokens de acceso. Las aplicaciones que utilizan libpq, como psql, son los clientes OAuth cuando se conectan a un clúster de PostgreSQL.
El sistema que aloja los recursos protegidos a los que accede el cliente. El clúster de PostgreSQL al que se conecta es el servidor de recursos.
La organización, proveedor del producto u otra entidad que desarrolla y/o administra los servidores de autorización y los clientes OAuth para una aplicación determinada. Los distintos proveedores suelen elegir diferentes detalles de implementación para sus sistemas OAuth; por lo general, no se garantiza que el cliente de un proveedor tenga acceso a los servidores de otro.
Este uso del término "proveedor" no es estándar, pero parece ser de uso común coloquialmente. (No debe confundirse con el término similar de OpenID "Proveedor de identidad" o Identity Provider. Aunque la implementación de OAuth en PostgreSQL está pensada para ser interoperable y compatible con OpenID Connect/OIDC, no es en sí misma un cliente OIDC y no requiere su uso).
El sistema que recibe las solicitudes del cliente y le expide los tokens de acceso una vez que el propietario del recurso autenticado ha dado su aprobación. PostgreSQL no proporciona un servidor de autorización; es responsabilidad del proveedor de OAuth.
Un identificador para un servidor de autorización, escrito como una URL https://, que proporciona un
"espacio de nombres" de confianza para las aplicaciones y los clientes OAuth. El identificador del emisor permite que un
único servidor de autorización hable con los clientes de entidades que no confían entre sí, siempre que mantengan
emisores independientes.
Para despliegues pequeños, puede no haber una distinción significativa entre el "proveedor", el "servidor de autorización" y el "emisor". Sin embargo, para configuraciones más complicadas, puede haber una relación de uno a muchos (o de muchos a muchos): un proveedor puede alquilar múltiples identificadores de emisor a diferentes inquilinos (tenants), y luego proporcionar múltiples servidores de autorización, posiblemente con diferentes conjuntos de características compatibles, para interactuar con sus clientes.
PostgreSQL admite tokens de portador (bearer tokens), definidos en la norma RFC 6750, que son un tipo de token de acceso utilizado con OAuth 2.0 en el que el token es una cadena opaca. El formato del token de acceso es específico de la implementación y es elegido por cada servidor de autorización.
Se admiten las siguientes opciones de configuración para OAuth:
issuerUna URL HTTPS que es el identificador exacto del emisor (issuer identifier) del servidor de autorización, tal y como define su documento de descubrimiento, o una URI bien conocida que apunta directamente a ese documento de descubrimiento. Este parámetro es obligatorio.
Cuando un cliente OAuth se conecta al servidor, se construirá una URL para el documento de descubrimiento utilizando el
identificador del emisor. Por defecto, esta URL utiliza las convenciones de OpenID Connect Discovery: la ruta
/.well-known/openid-configuration se añadirá al final del identificador del emisor.
Alternativamente, si el parámetro issuer contiene un segmento de ruta /.well-known/,
esa URL se proporcionará al cliente tal cual.
El cliente OAuth en libpq requiere que el ajuste del emisor del servidor coincida exactamente con el identificador del emisor que se proporciona en el documento de descubrimiento, que a su vez debe coincidir con el ajuste oauth_issuer del cliente. No se permiten variaciones en las mayúsculas o en el formato.
scopeUna lista separada por espacios de los alcances (scopes) de OAuth necesarios para que el servidor autorice al cliente y autentique al usuario. Los valores adecuados los determinan el servidor de autorización y el módulo de validación de OAuth utilizado (consulta la sección Chapter 50 para obtener más información sobre los validadores). Este parámetro es obligatorio.
validator
La biblioteca a utilizar para validar los tokens de portador. Si se proporciona, el nombre debe coincidir exactamente
con una de las bibliotecas indicadas en la sección oauth_validator_libraries. Este parámetro es
opcional a menos que oauth_validator_libraries contenga más de una biblioteca, en cuyo caso es obligatorio.
mapPermite la asignación entre el proveedor de identidad OAuth y los nombres de usuario de la base de datos. Consulta la sección Section 20.2 para más detalles. Si no se especifica un mapa, el nombre de usuario asociado al token (determinado por el validador de OAuth) debe coincidir exactamente con el nombre de rol solicitado. Este parámetro es opcional.
delegate_ident_mapping
Una opción avanzada que no está pensada para un uso común.
Cuando se configura con el valor 1, se omite la asignación estándar de usuarios con
pg_ident.conf, y el validador de OAuth asume toda la responsabilidad de asignar las identidades
de los usuarios finales a los roles de la base de datos. Si el validador autoriza el token, el servidor confía en que el
usuario tiene permitido conectarse bajo el rol solicitado, y se permite que la conexión proceda independientemente
del estado de autenticación del usuario.
Este parámetro es incompatible con map.
delegate_ident_mapping proporciona flexibilidad adicional en el diseño del sistema de autenticación,
pero también requiere una implementación cuidadosa del validador de OAuth, que debe determinar si el token proporcionado
conlleva suficientes privilegios de usuario final además de las comprobaciones estándar (standard checks) exigidas a todos los validadores. Utilízalo con precaución.