¿Cuál es la regla en una frase?

Si el cliente es suyo, use Sanctum; si es de otro, use Passport. Todo lo demás en la comparación se sigue de ahí, porque OAuth2 existe para dejar que un tercero actúe en nombre de un usuario sin tener su contraseña, que es un problema que usted no tiene con su propia aplicación.

¿Podemos empezar con Sanctum y cambiar después?

Sí, y es el orden correcto. Añadir Passport cuando aparezca de verdad una integración de terceros es un trabajo acotado, y los dos pueden convivir durante la transición. Empezar con Passport por si acaso es pagar por un problema que quizá nunca tenga.

¿Sanctum es menos seguro?

No. Emite tokens opacos guardados hasheados en su base de datos, con habilidades y revocación, y para un cliente propio esa es exactamente la forma correcta. OAuth2 no es más seguro en abstracto: resuelve la delegación, que es un problema distinto de la autenticación.

¿Cómo funciona el modo SPA?

No usa tokens en absoluto. Una aplicación de página única propia en el mismo dominio de nivel superior se autentica con la cookie de sesión de siempre, con la protección CSRF intacta, así que no hay ningún token en el almacenamiento del navegador que robar. Es la opción más segura disponible y es la que se salta la gente.

Sanctum vs Passport: casi todos eligen el caro

Passport implementa OAuth2, que es la respuesta correcta para clientes de terceros y un error caro para su propio frontend. La decisión gira sobre una pregunta - de quién es el cliente.

Publicado el 21 de septiembre de 20264 min de lectura

Esta es la decisión evitable más común en una API Laravel, y va en la dirección equivocada con la frecuencia suficiente como para merecer un artículo entero.

La pregunta no es qué paquete es mejor. Es quién tiene el token.

Para qué sirve OAuth2 en realidad

OAuth2 existe para que un tercero pueda actuar en nombre de un usuario sin que el usuario le entregue su contraseña. Ese es el problema que resuelve: delegación a través de una frontera de confianza. La pantalla de consentimiento, el código de autorización, las credenciales de cliente, los ámbitos: todo existe para hacer seguro ese intercambio concreto.

Si el cliente es su propia aplicación React o su propia app móvil, no hay frontera de confianza ni delegación. El usuario se está autenticando con usted, directamente. OAuth2 no resuelve nada aquí y le cobra la maquinaria igualmente.

Qué cuesta cuando está mal

Passport trae un servidor OAuth2 a su aplicación: tablas de clientes, códigos de autorización, tokens de acceso y de refresco, generación de claves, introspección de tokens, y una superficie de actualización que hay que mantener al día.

Su equipo mantiene ahora un servidor OAuth2. Va a depurar la rotación de tokens de refresco, explicarle a alguien las credenciales de cliente y encargarse de la rotación de claves en el despliegue. Todo para que su propia app móvil pueda iniciar sesión.

También se construye mal de una forma reconocible: se usa el grant de contraseña porque el flujo de redirección no tiene sentido para una app propia, el secreto de cliente se envía dentro de esa app donde no es ningún secreto, y alguien pone una vida de token de un año para que dejen de quejarse.

Sanctum, que es lo que quieren casi todas las APIs

Tokens opacos, guardados hasheados, con habilidades y revocación por token:

$token = $user->createToken('mobile', ['orders:read'])->plainTextToken;

Nada que levantar, nada que rotar, y revocar es borrar una fila. Para una app móvil, una CLI o una clave servidor a servidor emitida a un cliente, esa es la forma correcta.

Lo que se le escapa a la gente es que Sanctum tiene un segundo modo que es todavía mejor.

Para una SPA propia, ningún token

Si su aplicación de página única se sirve desde el mismo dominio de nivel superior que la API, Sanctum la autentica con la cookie de sesión de siempre:

GET  /sanctum/csrf-cookie      → pone la cookie CSRF
POST /login                    → login de sesión normal
GET  /api/orders               → autenticado por cookie, protegido con CSRF

Ningún token en localStorage, así que no hay nada que un fallo de cross-site scripting pueda robar. HttpOnly, SameSite, protección CSRF: el conjunto entero de protecciones del navegador al que renuncia la autenticación con token en almacenamiento.

Los equipos se lo saltan porque "es una API, así que necesita tokens". No los necesita, y esta es la disposición más segura disponible para un cliente de navegador propio.

Cuándo Passport es realmente lo correcto

Aplicaciones de otras empresas se integran con usted. Necesitan actuar por sus usuarios, usted necesita pantallas de consentimiento y acceso acotado, y necesita revocar una integración sin tocar ninguna otra.

Usted es el proveedor de identidad. Otros sistemas se autentican contra usted.

Un requisito de estándar. Un socio o un proceso de compras especifica OAuth2 y eso no se negocia.

Fíjese en lo que tienen en común: alguien de fuera de su organización tiene la credencial. Esa es toda la prueba.

Migrar entre ellos

De Passport a Sanctum, donde Passport se eligió por error: emita tokens Sanctum al iniciar sesión, acepte los dos durante una ventana de transición, deje de emitir tokens Passport y quítelo. Acotado, y normalmente una semana.

De Sanctum a Passport, cuando aparece una integración de terceros de verdad: instale Passport para los flujos de terceros y quédese Sanctum para sus propios clientes. Conviven, con guards distintos. Esa es otra razón por la que empezar con Sanctum no le cuesta nada: no se está metiendo en un rincón, simplemente no está pagando por adelantado.

La regla, una vez más

Su cliente, su token: Sanctum. El cliente de otro actuando por su usuario: Passport.

Si no puede nombrar al tercero, todavía no necesita OAuth2, y la política de versiones que escriba para esa API le importará mucho más a sus consumidores que qué paquete emitió el token.