Autenticación local con Passport en NestJS

Contenido del curso

Fundamentos y Primer CRUD

Base de Datos y Persistencia con TypeORM

Autenticación y Autorización

Tu API Completa

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0019:16

Autenticación local con Passport en NestJS

Curso de Backend con NestJS

Clase 26 de 35

Clase 26 / 35

Recursos

La autenticación local con Passport en NestJS te permite proteger endpoints, validar credenciales contra tu base de datos y restringir funcionalidades a usuarios logueados. Si ya tienes el password hasheado y excluido de las respuestas, el siguiente paso lógico es montar el flujo de login con email y contraseña.

¿Qué es Passport y por qué usarlo en NestJS?

Passport es una de las librerías más populares del ecosistema Node para gestionar autenticación, y NestJS ofrece un paquete oficial que la integra de forma natural.

Con Passport puedes manejar múltiples strategies: login local con usuario y contraseña, JWT para sesiones, o autenticación con redes sociales como Facebook, Google o Twitter. La idea es que cada estrategia encapsula una forma distinta de validar identidad, y puedes combinarlas dentro de la misma aplicación.

En este flujo vas a trabajar con la estrategia local, que es la base de cualquier sistema de login tradicional con email y password [2:00].

¿Qué es una strategy en Passport? Es un módulo que define cómo validar credenciales para un método específico de autenticación, por ejemplo local, JWT o OAuth con redes sociales.

¿Qué paquetes necesitas instalar?

Para arrancar la integración necesitas tres dependencias clave en tu proyecto:

@nestjs/passport, el wrapper oficial de NestJS.
passport y passport-local, la librería base y la estrategia local.
@types/passport-local, los tipos para TypeScript.

¿Cómo estructurar el módulo de autenticación?

La recomendación oficial es crear un módulo dedicado para auth, separado del módulo de usuarios. Lo generas con nest generate module auth y luego creas su servicio correspondiente.

Dentro de UsersService necesitas un método nuevo: getUserByEmail. Este método recibe un email como string, ejecuta un findOne en el repositorio y retorna el usuario asociado. Las validaciones de existencia no van aquí, sino en el módulo de autenticación, para lanzar las excepciones correctas en el lugar correcto [5:30].

typescript async getUserByEmail(email: string) { return this.userRepository.findOne({ where: { email } }); }

¿Cómo compartir servicios entre módulos en NestJS?

Aquí entra un concepto fundamental: la cooperación entre módulos. Para que AuthService pueda usar UsersService, necesitas dos pasos.

Exponer UsersService en el array exports del UsersModule.
Importar UsersModule (no el servicio) en el array imports del AuthModule.

Un error común es poner el módulo importado dentro de providers. Eso rompe la aplicación con un mensaje del tipo user service is provider. Los providers son servicios; los módulos van en imports. Esa distinción es la que permite que NestJS resuelva correctamente la inyección de dependencias.

¿Cómo implementar el método validateUser?

El corazón de la estrategia local es un método llamado validateUser dentro de AuthService. Recibe el email y el password en bruto, y devuelve el usuario solo si todo coincide.

El flujo tiene tres momentos:

Buscar el usuario con getUserByEmail.
Si no existe, lanzar una excepción UnauthorizedException.
Comparar el password recibido contra el hash almacenado usando bcrypt.compare.

typescript async validateUser(email: string, password: string) { const user = await this.usersService.getUserByEmail(email); if (!user) throw new UnauthorizedException(); const isMatch = await bcrypt.compare(password, user.password); if (!isMatch) throw new UnauthorizedException(); return user; }

Un detalle de seguridad importante: nunca respondas con user not found. Si lo haces, le confirmas al atacante qué emails están registrados, lo que facilita ataques de fuerza bruta. Devuelve siempre unauthorized sin distinguir entre email inexistente o password incorrecto [9:15].

¿Por qué no decir si el email existe? Porque revelar esa información permite enumerar cuentas registradas. Un mensaje genérico de unauthorized protege la privacidad de tus usuarios.

¿Por qué no necesitas excluir el password manualmente?

La documentación oficial sugiere extraer el password del objeto antes de retornarlo. Si ya configuraste el select: false en la entidad o usas un transformer en el repositorio, ese paso es innecesario. El password queda excluido automáticamente de la respuesta, lo que mantiene tu código más limpio.

¿Cómo crear la LocalStrategy personalizada?

Passport por defecto espera un campo llamado username. Si tu sistema usa email, necesitas configurarlo explícitamente en una clase que extienda de PassportStrategy.

La convención es crear una carpeta strategies/ dentro de auth/ y añadir ahí local.strategy.ts. Esto te permite agregar más estrategias en el futuro (JWT, Google, Twitter) manteniendo el orden.

typescript @Injectable() export class LocalStrategy extends PassportStrategy(Strategy, 'local') { constructor(private authService: AuthService) { super({ usernameField: 'email', passwordField: 'password' }); }

async validate(email: string, password: string) { return this.authService.validateUser(email, password); } }

El segundo parámetro 'local' es el nombre de la estrategia. Es buena práctica nombrarla porque te servirá para referenciarla desde guards más adelante.

¿Qué configuración falta en AuthModule?

Una vez creada la estrategia, queda registrar todo en AuthModule:

Importar PassportModule desde @nestjs/passport en el array imports.
Importar UsersModule para acceder a UsersService.
Registrar LocalStrategy como un provider más, junto a AuthService.

Con esa configuración, el módulo queda listo para validar credenciales contra la base de datos. El siguiente paso natural es exponer un endpoint en un controller que reciba email y password, dispare esta cadena de validación y devuelva la respuesta de login.

¿Ya tienes claro cómo conectarías una segunda estrategia, como JWT, sobre esta misma base? Cuéntame en los comentarios cómo estás organizando tus módulos de auth.

Andrés Castellanos

Hace 6 meses

¿Por qué es importante el uso de Passpot? porque nos permite desacoplar la estrategia de autorización

¿Por qué no hacer simplemente esto?

@Post('login')
async login(@Body() body) {
  return this.authService.validateUser(body.email, body.password);
}

si queremos cambiar de estrategia tendriamos que modificar el controller del modulo auth.

¿Qué pasa cuando queremos hacer autenticación sin passport?

tendriamos que repetir esta logica para cada endpoint (usando JWT)

@Get('profile')
async profile(@Req() req: Request) {
  const token = req.headers.authorization?.split(' ')[1];

  const user = this.authService.verifyToken(token);

  return user;
}

y estaríamos acoplando todos los endpoints a auth con JWT.

Passport permite abstraer la logica de authentication para evitar repetir código y desacoplarnos

@Get('profile')
@UseGuards(AuthGuard('jwt'))
getProfile(@Req() req) {
  return req.user;
}

sin embargo aqui seguimos acoplando toda nuestra app a jwt, si es probable que nuestra pp cambie a session o api-key, o oauth, en un futuro... Entonces es mejor crear una capa de abstracción exclusivamente para decirle a passport que estrategia usar, para ello podemos crear un custom guard

en src/auth/guards/auth.guard.ts

// src/auth/guards/auth.guard.ts
import { Injectable } from '@nestjs/common';
import { AuthGuard as PassportAuthGuard } from '@nestjs/passport';

@Injectable()
export class AuthGuard extends PassportAuthGuard('jwt') {}

y en nuestra app

@UseGuards(AuthGuard)
@Get('orders')
getOrders(@Req() req) {
  return this.ordersService.findByUser(req.user.id);
}

De esta forma si en un futuro cambiamos de estrategia solo se modifica un archivo: src/auth/guards/auth.guard.ts

Fundamentos y Primer CRUD

Crea una API RESTful con NestJS

Instalación del CLI de NestJS y primer proyecto con API

Creación de endpoints dinámicos para consultar usuarios en NestJS

Operaciones CRUD en APIs REST con Postman

Método PUT para actualizar usuarios con ID automático

Manejo de status codes HTTP en NestJS

DTOs y validación automática de datos en APIs con NestJS

Servicios y lógica de negocio en NestJS

Variables de entorno seguras en NestJS

Programación modular en NestJS con UserModule

Base de Datos y Persistencia con TypeORM

Configuración de PostgreSQL con Docker y Docker Compose

Configuración de PostgreSQL con TypeORM en aplicaciones NestJS

Creación de entidades ORM con decoradores en TypeScript

Repository Pattern con TypeORM en NestJS

Relaciones uno a uno entre usuarios y perfiles en PostgreSQL

Actualización de DTOs con mapped types en NestJS para perfil y usuario

Generación automática de módulos CRUD con NestJS y AI

Relación uno a muchos con TypeORM

CRUD de categorías con IA en NestJS

Relaciones many-to-many con TypeORM y validación de arrays

Reutilización de servicios entre módulos en NestJS

Migraciones en TypeORM sin perder datos

Cómo evitar perder datos al migrar columnas

Autenticación y Autorización

Hashing de contraseñas con Bcrypt en NestJS

Excluir campos sensibles con ClassTransformer

Autenticación local con Passport en NestJS

Endpoint de login con Passport en NestJS

Implementación de JSON Web Token para autenticación en NestJS

Rutas protegidas con JWT en NestJS

User ID automático desde JWT en NestJS

Tu API Completa

Autogenera resúmenes e imágenes con OpenAI en NestJS

Documentación automática de APIs con Swagger en NestJS

Preparar tu API NestJS para producción

Desplegar aplicación Node.js a producción con Railway y PostgreSQL

Desarrollo de API REST escalable con NestJS en producción

Autenticación local con Passport en NestJS