Autorizadores y autenticación de API

Una puerta de enlace de API como la de AWS ofrece varias formas de controlar el acceso: roles de IAM para llamadas de otros servicios o de cuentas propias, autorizadores de Lambda que ejecutan tu lógica sobre la petición y autorizadores respaldados por un servicio de identidad como Amazon Cognito. En Azure API Management la política validate-jwt cumple un papel parecido. Cuando los usuarios traen tokens de un proveedor de identidad externo, lo que se necesita es validar esos tokens contra el emisor y la audiencia esperados.

Un token de otra aplicación puede traer una firma perfectamente válida y aun así no estar dirigido a esta API. La comprobación que lo separa es la audiencia (aud). Mira token-ejemplo-decodificado.json para ver qué reclamaciones trae un token de api-mirlo y autorizador-aut-clientes.json para ver qué espera el autorizador.

Abre rutas-api-mirlo.txt. Una ruta sin autorizador no es un fallo por sí misma: una consulta pública por código de seguimiento puede serlo a propósito, y la documentación lo dice. El hallazgo es la ruta que no está documentada como pública y aun así no exige autenticación, sobre todo si mueve dinero o datos.

Un autorizador de Lambda puede guardar su decisión en caché durante un tiempo (resultTtlInSeconds) para no ejecutarse en cada petición. Es una ganancia de rendimiento con un costo: mientras la decisión siga en caché, un token que ya se revocó o un usuario ya deshabilitado puede seguir pasando.

Los registros del autorizador cuentan la historia de un día: quién pidió qué y por qué se negó. Un rechazo por alcance (scope) indica que el token era válido pero no tenía el permiso que la ruta exige. Abre decisiones-aut-clientes.log.