A modo de ejemplo, echemos un vistazo a cómo funciona la autenticación con Kubernetes :
Específicamente,concentrémonosenloquehaceelservidorapi.Paraautenticarlasolicitud,ésta:
¡Debe haber más que esto! Lo que pasa con los proveedores de OIDC es que entregarán tokens con firmas válidas a casi cualquier persona. Por ejemplo, digamos que quiero usar Google como mi proveedor de identidad. Si el único requisito fuera que la firma JWT es válida, un atacante podría configurar algún sitio que me gustaría, por ejemplo, con fotos graciosas de gatos. En algún momento visito el sitio e inicio sesión, y en el bingo, el atacante tiene una JWT de identidad con una firma válida y mi nombre en ella. Sería bastante malo si el propietario de funnycatpictures.com ahora pudiera acceder al servidor de la API de Kubernetes con mi nombre.
Entonces, ¿cuáles son específicamente las restricciones que impiden este ataque?
Mi entendimiento es que el reclamo aud (audiencia) en el JWT es parte de él: Kubernetes debe aceptar el token solo si aud contiene su ID de cliente OAuth. Esto debería significar que no se aceptarán tokens emitidos a otros clientes de OAuth (como el sitio de fotos de gatos graciosos) porque tendrán el aud incorrecto.
Sin embargo, parece haber una forma de evitar esto con el flujo de concesión implícito, que no requiere un secreto de cliente OAuth. Como tal, funnycatpictures.com podría usar el flujo implícito pero con el ID de cliente de Kubernetes, obteniendo así los tokens con el aud correcto que sería aceptado por el servidor de API de Kubernetes.
¿Qué previene tal ataque?