Configuraciones de federación con errores de diseño

En el flujo de código de autorización, el IdP devuelve el código a la dirección de retorno (redirect_uri) que el cliente registró. Esa dirección es lo único que impide que el código llegue a otro sitio. Si se registra con un comodín que acepta cualquier subdominio, el IdP entregará códigos a cualquier máquina que cuelgue de ese dominio: un entorno de pruebas olvidado, un subdominio que apunta a un servicio dado de baja o uno que otra área publica sin control. La guía de seguridad actual de OAuth 2.0 (RFC 9700) pide comparar la dirección de forma exacta.

Abre el laboratorio y lee configuraciones.txt con la regla PF-2 de politica-de-federacion.txt.

Un secreto de cliente identifica a una aplicación ante el IdP. Si varios clientes comparten el mismo, el IdP ya no puede distinguirlos: cualquiera de ellos puede presentarse como los demás, una fuga en el menos cuidado compromete a todos y rotarlo exige coordinar a varios equipos a la vez, así que nadie lo rota. Cuando además uno de esos clientes vive en el servidor de un socio, el secreto ya salió de la empresa.

El IdP firma con una clave cuyo certificado tiene vida limitada, y algún día lo cambia. Si cada parte que confía lee los metadatos del IdP y acepta los dos certificados durante la transición, el cambio pasa sin que nadie lo note. Si una parte tiene el certificado cargado a mano, el día del cambio deja de aceptar las aserciones nuevas y nadie puede entrar. No es un riesgo de ataque: es una caída programada que solo se ve leyendo la configuración antes de tiempo.

Lee aviso-de-rotacion.txt y las filas de certificados de configuraciones.txt.

Los relojes de los sistemas nunca coinciden del todo, así que quien valida una aserción o un token admite un margen al comparar las horas de inicio y fin de validez. Unos pocos minutos cubren la diferencia real entre relojes sincronizados. Un margen mucho mayor no arregla nada que valga la pena y cambia el significado de la vigencia que el IdP fijó.