Autenticación en Laravel: login, sesiones, Sanctum y permisos

Autenticación y autorización no son lo mismo

Esta distinción es una de las bases de cualquier sistema multiusuario.

Autenticación

Responde:

¿Quién eres?

Por ejemplo, después de introducir email y contraseña, la aplicación determina que la solicitud pertenece al usuario 145.

Autorización

Responde:

¿Puedes realizar esta acción?

El usuario 145 puede estar autenticado, pero eso no significa que pueda editar el pedido del usuario 892.

Solicitud
    ↓
¿Quién eres?
    ↓
Autenticación
    ↓
¿Qué puedes hacer?
    ↓
Autorización
    ↓
Acción

Crear un usuario comienza validando y almacenando correctamente sus credenciales

Una implementación simplificada puede recibir:

Primero validamos.

<?php

$datos = $request->validate([
    'name' => [
        'required',
        'string',
        'max:150'
    ],
    'email' => [
        'required',
        'email',
        'max:255',
        'unique:users,email'
    ],
    'password' => [
        'required',
        'confirmed'
    ]
]);

La contraseña nunca debería almacenarse como texto plano.

<?php

use Illuminate\Support\Facades\Hash;

$user = User::create([
    'name' => $datos['name'],
    'email' => $datos['email'],
    'password' => Hash::make(
        $datos['password']
    )
]);

Una vez autenticado puedes obtener al usuario de la solicitud

<?php

$user = $request->user();

También puedes utilizar la fachada Auth.

<?php

use Illuminate\Support\Facades\Auth;

$user = Auth::user();

$userId = Auth::id();

A partir de esa identidad puedes comenzar a aplicar reglas de autorización.

Logout no consiste solamente en redirigir al usuario

En autenticación basada en sesión puedes cerrar la sesión mediante Auth.

<?php

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

public function logout(
    Request $request
) {
    Auth::logout();

    $request->session()
        ->invalidate();

    $request->session()
        ->regenerateToken();

    return redirect('/');
}

De esta manera eliminas la información de autenticación, invalidas la sesión anterior y renuevas la protección CSRF.

“Recordarme” modifica la duración práctica de la autenticación

Si tu aplicación ofrece esta opción, la decisión debería ser explícita.

$remember = $request->boolean(
    'remember'
);

if (Auth::attempt(
    $credentials,
    $remember
)) {

    $request->session()
        ->regenerate();

}

No todos los sistemas necesitan sesiones persistentes.

Una aplicación financiera, un panel administrativo o una plataforma con datos sensibles puede requerir políticas diferentes a un sitio de consumo general.

Sanctum cubre dos necesidades relacionadas, pero diferentes

Sanctum puede ayudarte con:

Puedes instalar el soporte API mediante:

php artisan install:api

Después la estrategia concreta dependerá de si estás construyendo:

una SPA, una aplicación móvil, una integración o una API para terceros.

El model de usuario puede emitir tokens mediante Sanctum

Para trabajar con personal access tokens, el model puede utilizar el trait correspondiente.

<?php

use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasApiTokens;
}

Después puedes generar un token.

$token = $user
    ->createToken('mobile');

return [
    'token' =>
        $token->plainTextToken
];

auth:sanctum protege rutas que necesitan una identidad autenticada

<?php

Route::get(
    '/usuario',
    function (Request $request) {

        return $request->user();

    }
)->middleware('auth:sanctum');

También puedes proteger un grupo completo.

Route::middleware(
    'auth:sanctum'
)->group(function () {

    Route::post(
        '/productos',
        [ProductoController::class, 'store']
    );

    Route::patch(
        '/productos/{producto}',
        [ProductoController::class, 'update']
    );

});

Esto verifica la autenticación.

Todavía necesitamos resolver si ese usuario puede crear o modificar ese producto.

Una SPA autenticada mediante cookies debe considerar protección CSRF

Antes del login, el frontend puede inicializar la protección CSRF utilizando el endpoint de Sanctum.

GET /sanctum/csrf-cookie

Después, el cliente puede enviar la solicitud de login.

GET /sanctum/csrf-cookie
          ↓
POST /login
          ↓
Sesión Laravel
          ↓
Cookie
          ↓
auth:sanctum

Esto es diferente a la estrategia donde un cliente externo envía un Bearer token en cada request.

Un cliente basado en token envía la credencial en cada solicitud

Authorization: Bearer TU_TOKEN

Este enfoque puede resultar apropiado para determinados:

No confundas token con usuario

El token es una credencial utilizada para asociar una solicitud con una identidad.

La identidad y sus permisos siguen siendo conceptos separados.

Puedes limitar qué capacidades tiene un token

Un token no necesariamente necesita acceso total.

$token = $user->createToken(
    'integracion-stock',
    [
        'productos:read',
        'stock:update'
    ]
);

Después puedes comprobar si la credencial posee una capacidad.

if (
    $request->user()
        ->tokenCan('stock:update')
) {

    // El token declara esta capacidad.

}

La duración de un token también forma parte del modelo de seguridad

Una integración interna, una app móvil y un acceso temporal pueden necesitar políticas diferentes.

Puedes diseñar tokens con una fecha de expiración cuando sea apropiado.

$token = $user->createToken(
    'acceso-temporal',
    ['productos:read'],
    now()->addDays(7)
);

Expirar tokens no elimina la necesidad de poder revocarlos antes.

Después del login necesitas decidir quién puede hacer qué

Imagina una aplicación con proyectos.

Un usuario intenta:

PATCH /api/proyectos/856

El usuario puede tener:

Y aun así no ser propietario de ese proyecto.

Ese último problema no pertenece al login.

Pertenece a la autorización.

La autorización debería ejecutarse antes de realizar una acción sensible

Una ruta puede aplicar autorización antes de ejecutar la lógica.

Route::patch(
    '/proyectos/{proyecto}',
    [ProyectoController::class, 'update']
)->can(
    'update',
    'proyecto'
);

Si el usuario no está autorizado, la solicitud no debería continuar como si tuviera permiso.

Gates son útiles para permisos que no necesariamente pertenecen a un model concreto

Por ejemplo, acceder a un dashboard administrativo.

<?php

use Illuminate\Support\Facades\Gate;

Gate::define(
    'ver-panel-administracion',
    function (User $user): bool {

        return $user->es_admin;

    }
);

Conceptualmente:

Permiso general
    ↓
Gate

Acción sobre un recurso
    ↓
Policy

No necesitas escoger una de las dos herramientas para toda la aplicación.

Pueden convivir.

En aplicaciones SaaS, estar autenticado tampoco significa pertenecer a la empresa correcta

Imagina dos empresas:

Empresa A
 ├── Usuario 1
 └── Proyecto 10

Empresa B
 ├── Usuario 2
 └── Proyecto 900

El Usuario 1 puede estar perfectamente autenticado.

Pero no debería poder obtener:

GET /api/proyectos/900

si ese proyecto pertenece a la Empresa B.

El aislamiento debe aplicarse en el backend

No basta con que el frontend nunca muestre el ID 900.

Un endpoint de login no debería aceptar intentos ilimitados sin controles

Una persona puede equivocarse al escribir su contraseña.

Un atacante también puede automatizar miles de intentos.

Por eso un sistema de autenticación profesional debería considerar límites adecuados para operaciones sensibles.

email + contraseña 1
email + contraseña 2
email + contraseña 3
email + contraseña 4
...
miles de intentos

El objetivo no es bloquear indiscriminadamente a usuarios legítimos, sino aumentar el costo de la automatización maliciosa.

Autenticar una cuenta no demuestra automáticamente que controla el email registrado

Para determinadas aplicaciones puede ser importante verificar la dirección de correo.

Esto resulta especialmente útil cuando el email será utilizado para:

Nuevamente:

email verificado, usuario autenticado y usuario autorizado son tres afirmaciones diferentes.

Cambiar una contraseña puede requerir invalidar sesiones activas en otros dispositivos

Imagina que una cuenta estaba abierta en un equipo perdido.

Cambiar la contraseña puede no ser suficiente si mantienes sesiones antiguas válidas sin una política definida.

En determinados escenarios puedes requerir cierre de otras sesiones después de confirmar la contraseña actual.

Auth::logoutOtherDevices(
    $currentPassword
);

Las decisiones de sesiones deberían responder al riesgo de la aplicación.

No necesitas implementar OAuth2 completo para cada API Laravel

Sanctum cubre muy bien muchos escenarios habituales:

SPA, móvil, first-party UI y APIs con tokens sencillos.

Passport cobra sentido cuando realmente necesitas las capacidades completas de un servidor OAuth2.

SPA propia
        ↓
Sanctum

App móvil propia
        ↓
Sanctum

API tokens sencillos
        ↓
Sanctum

OAuth2 completo
        ↓
Evaluar Passport

Qué evitar al implementar autenticación en Laravel

Un buen sistema de autenticación identifica al usuario sin confundir identidad con permisos