Si ya integraste un API key en tu proyecto Serverless y necesitas validar reglas de negocio reales, un custom authorizer te permite ejecutar lógica propia (como validar un JWT) en lugar de depender de una cadena estática. Esta guía es para desarrolladores backend que quieren proteger sus Lambdas con autenticación dinámica y secretos bien gestionados.

¿En qué se diferencia un API key de un custom authorizer?

La distinción es clave antes de escribir una sola línea de código.

Un API key es una cadena de texto constante. No cambia en el tiempo y no permite ejecutar lógica adicional. Sirve para identificar quién consume tu API, pero no para validar reglas de negocio.

Un custom authorizer, como su nombre indica, es personalizable. Puedes definir cualquier estrategia de autorización: validar un JWT, consultar una base de datos, revisar permisos por rol o combinar varias condiciones.

¿Cuándo usar un custom authorizer en vez de un API key? Cuando necesites validar tokens dinámicos, aplicar reglas de negocio o autorizar peticiones según el contexto del usuario. El API key solo identifica, no autoriza con lógica.

¿Por qué no debes guardar el secreto en el serverless.yaml?

Aquí viene lo interesante. Para que un custom authorizer funcione, normalmente necesitas un secreto, por ejemplo, para firmar y verificar JWT.

La tentación es declarar una variable como secret_ek directamente en el archivo serverless.yaml con el valor quemado. Técnicamente funciona, pero es una muy mala práctica. ¿La razón? Cuando subes el repositorio a GitHub y arranca el proceso automatizado de despliegue, ese valor queda visible para cualquier persona con acceso al código. Tu secreto deja de ser secreto.

En proyectos reales, exponer un secreto en el repositorio puede comprometer toda la cadena de autenticación.

¿Cómo protejo el secreto con AWS Systems Manager Parameter Store?

La solución que se integra de forma natural con Serverless Framework es AWS Systems Manager Parameter Store, un servicio que te permite guardar parámetros de configuración y secretos fuera del código [02:10].

Crear el parámetro en la consola de AWS

Desde la consola de AWS, busca el servicio Systems Manager y entra a la sección Parameter Store. Allí crea un nuevo parámetro siguiendo estos pasos:

• Asigna un nombre identificable, por ejemplo SecretEk.
• Coloca el valor real del secreto, el mismo que tenías quemado en el código.
• Selecciona el tipo SecureString para que AWS lo cifre dentro de sus servidores.
• Guarda el parámetro.

Usar SecureString añade una capa extra de seguridad: el valor queda codificado en disco y solo es visible para quienes tengan el rol IAM adecuado para leerlo.

¿Qué es un SecureString en Parameter Store? Es un tipo de parámetro cifrado por AWS que solo pueden leer los roles autorizados. Ideal para guardar contraseñas, tokens o claves de firma.

Referenciar el secreto desde serverless.yaml

Una vez creado el parámetro, ya no necesitas el valor quemado. Serverless Framework permite traerlo dinámicamente con esta sintaxis:

yaml environment: SECRET_EK: ${ssm:/SecretEk}

Usas el signo de dólar, dos llaves y la referencia ssm/ seguida del nombre del parámetro. En el momento del despliegue, Serverless resuelve el valor desde Parameter Store y lo inyecta como variable de entorno.

Esto funciona igual que cuando defines un bucket como variable de ambiente: la variable queda disponible automáticamente en todas tus Lambdas, lista para que el custom authorizer la consuma.

¿Qué habilidades y conceptos quedan listos para el authorizer?

Antes de escribir la lógica del authorizer, conviene fijar las piezas que ya tienes en su sitio.

• API key vs custom authorizer: el primero es estático, el segundo ejecuta lógica personalizada como validar un JWT [00:45].
• AWS Systems Manager Parameter Store: servicio para almacenar parámetros y secretos fuera del código [02:30].
• SecureString: tipo de parámetro cifrado por AWS, accesible solo con el rol IAM correcto [03:15].
• Referencia ssm en serverless.yaml: sintaxis ${ssm:/NombreDelParametro} para inyectar secretos en tiempo de despliegue [03:50].
• Variables de entorno en Lambda: cualquier valor declarado en environment queda disponible en todas las funciones del proyecto [04:20].

Con el secreto protegido y disponible como variable de entorno, el siguiente paso es escribir la función authorizer que use ese valor para validar las peticiones entrantes. ¿Cómo estás gestionando hoy los secretos en tus proyectos Serverless? Cuéntame en los comentarios.