Configurar el inicio de sesión en una API con Laravel implica algo más que generar un token desde la terminal. Necesitas una ruta pública, un controlador dedicado y una validación segura de credenciales para que cualquier aplicación cliente pueda autenticarse y recibir su token de acceso.

Este flujo es el mismo que usan apps móviles y SPAs cuando piden email, contraseña y nombre del dispositivo para devolver un token reutilizable.

Cómo defines la ruta pública de login en la API

La ruta de inicio de sesión debe vivir fuera del grupo protegido por autenticación, porque un invitado todavía no tiene token cuando intenta entrar [01:00].

En el archivo de rutas API declaras un endpoint login que apunta a un método store dentro de un nuevo LoginController. Esa separación mantiene limpia la lógica: una ruta para entrar, el resto del grupo para usuarios ya autenticados.

Para generar el controlador usas el comando de Artisan y lo guardas dentro de la carpeta API:

bash php artisan make:controller API/LoginController

¿Por qué la ruta de login va fuera del middleware de autenticación? Porque el usuario aún no tiene token. Si la proteges, nunca podría iniciar sesión. La ruta debe ser accesible como invitado.

Qué validaciones necesita el método store del LoginController

Dentro del método store recibes el Request y aplicas reglas claras antes de tocar la base de datos [03:10]. El usuario debe enviar tres campos obligatorios.

• email: requerido y con formato válido de correo.
• password: requerido para comparar contra la contraseña guardada.
• device_name: requerido para identificar desde dónde se conecta, por ejemplo iPhone, Android o una versión específica de la app.

El device_name es clave porque Sanctum lo usa como etiqueta del token. Así puedes ver qué dispositivos tienen sesión abierta y revocar uno sin afectar al resto.

Cómo verificas la contraseña con la fachada Hash

Después de validar, consultas el usuario con User::where('email', $request->email)->first(). Aquí entra la parte interesante: no puedes comparar contraseñas en texto plano porque en la base de datos están encriptadas [05:20].

La fachada Hash de Laravel resuelve esto. El método Hash::check() toma la contraseña que envía el usuario y la compara contra el hash almacenado, devolviendo true o false.

php if (!$user || !Hash::check($request->password, $user->password)) { return response()->json([ 'message' => 'Las credenciales son incorrectas' ], Response::HTTP_UNPROCESSABLE_ENTITY); }

Fíjate en la condición: si el usuario no existe o la contraseña no coincide, devuelves el mismo error. Esto evita filtrar pistas sobre qué cuentas existen en tu sistema.

¿Qué hace Hash::check exactamente? Recibe la contraseña en texto plano y el hash guardado. Internamente reaplica el algoritmo de encriptación y compara los resultados, sin nunca desencriptar nada.

Por qué el código de estado 422 es el correcto

Cuando las credenciales fallan, devuelves Response::HTTP_UNPROCESSABLE_ENTITY, que corresponde al código 422. Es la respuesta estándar cuando la petición está bien formada pero los datos no se pueden procesar, justo el caso de un email o password inválidos.

Usar la constante de Symfony en lugar del número suelto hace tu código más legible y evita errores de tipeo.

Cómo generar y devolver el token de acceso al usuario

Si la validación pasa y la contraseña coincide, llegas al camino feliz: emitir el token [08:40]. Aquí aprovechas el método createToken() de Sanctum sobre la instancia del usuario, pasándole el nombre del dispositivo recibido en la petición.

La respuesta JSON sigue una estructura limpia con datos y atributos:

php return response()->json([ 'data' => [ 'attributes' => [ 'id' => $user->id, 'name' => $user->name, 'email' => $user->email, 'token' => $user->createToken($request->device_name)->plainTextToken, ] ] ], Response::HTTP_OK);

Devuelves el id, name, email y el token que la aplicación cliente guardará para autenticar las próximas peticiones. El estado 200 OK confirma que el login fue exitoso.

Qué clases necesitas importar en el controlador

Para que todo funcione, asegúrate de importar tres dependencias en la cabecera del archivo:

• Illuminate\Support\Facades\Hash para verificar la contraseña.
• Symfony\Component\HttpFoundation\Response para usar las constantes de estado HTTP.
• App\Models\User para consultar la tabla de usuarios.

Cómo probar el endpoint de login en Postman

Con el código listo, abres Postman y haces un POST a /api/login con header Accept: application/json para forzar respuestas JSON [11:30].

En el cuerpo envías el email registrado por el seeder, por ejemplo admin@admin.com, la contraseña password y el device_name como iPhone. Al enviar la petición, recibes el objeto con los atributos del usuario y el token recién creado.

Si cambias la contraseña por una incorrecta, la API responde con el mensaje "Las credenciales son incorrectas" y el estado 422. Si omites el device_name, el validador lanza el error pidiendo ese campo. Cada respuesta confirma que las reglas funcionan.

El punto importante: el flujo de autenticación con tokens es un estándar que está por encima de Laravel. Existen usuarios, existen tokens de acceso y existe un proceso de verificación de identidad. Aprende la capa conceptual y la herramienta deja de ser el obstáculo.

¿Te animas a extender este controlador con un endpoint de logout que revoque el token actual? Cuéntame cómo lo resolverías.