Ir al contenido principal

Laravel Sanctum: first party domain y first party session

De

  Los dominios de primera parte (first party domain) y las sesiones de primera parte (first party session) son conceptos clave para entender cómo funciona la autenticación de SPAs en Laravel Sanctum y cómo se diferencia de la autenticación por tokens de API.

En el contexto de Laravel Sanctum:

¿Qué es un "First-Party Domain" (Dominio de Primera Parte)?

Un "dominio de primera parte" (o "first-party domain") se refiere al escenario en el que tu aplicación frontend (SPA, por ejemplo, React, Vue, Angular) y tu API de Laravel backend comparten el mismo dominio de nivel superior.

Ejemplos de dominios de primera parte:

  • Producción:
    • Frontend: app.example.com
    • Backend (API): api.example.com
    • Ambos comparten el dominio de nivel superior example.com.
  • Desarrollo local:
    • Frontend: localhost:3000 (o localhost:5173 para Vite, etc.)
    • Backend (API): localhost:8000 (o 127.0.0.1:8000 con php artisan serve)
    • Ambos comparten el dominio de nivel superior localhost.

Lo crucial es que el navegador los considere parte del mismo "sitio" para fines de seguridad de cookies y CORS.

¿Por qué es importante el "First-Party Domain" en Sanctum?

Porque Laravel Sanctum utiliza esta condición para ofrecer un método de autenticación para SPAs que es similar a la autenticación de sesión tradicional basada en cookies de Laravel, pero adaptado a las necesidades de las SPAs.

Cuando una solicitud HTTP entrante a tu API de Laravel proviene de un dominio que has configurado como "first-party" en tu archivo config/sanctum.php (a través de la variable de entorno SANCTUM_STATEFUL_DOMAINS), Sanctum intentará autenticar la solicitud usando las cookies de sesión de Laravel.

Este comportamiento es ideal porque:

  • Es familiar: Funciona de manera muy similar a cómo Laravel siempre ha manejado la autenticación web.
  • Seguridad: Se beneficia de las protecciones incorporadas de Laravel, como la protección CSRF (Cross-Site Request Forgery) y la protección contra ataques XSS (Cross-Site Scripting) para las credenciales de autenticación.
  • Conveniencia: No necesitas manejar manualmente tokens de API en el lado del frontend para la autenticación; las cookies lo hacen por ti después de una solicitud inicial para obtener el token CSRF (/sanctum/csrf-cookie).

¿Está relacionado con "First-Party Session"?

Sí, están intrínsecamente relacionados y son la base de la autenticación de SPAs en Sanctum.

Cuando hablamos de "first-party session" en el contexto de Sanctum, nos referimos al mecanismo de autenticación basado en sesiones y cookies de Laravel que se activa específicamente cuando la solicitud proviene de un "first-party domain" configurado.

Laravel Sanctum tiene dos modos principales de autenticación:

  1. Autenticación por Tokens de API (Stateless): Para aplicaciones móviles, terceros, o SPAs que están en un dominio diferente (cross-origin). Aquí el cliente envía un token de tipo Bearer en el encabezado Authorization. Esta es una autenticación sin estado (stateless).
  2. Autenticación de SPA (Basada en Sesión de Primera Parte / Stateful): Para SPAs que residen en un "first-party domain" con respecto a la API. Para estas solicitudes, Sanctum utiliza las sesiones y cookies de Laravel, haciendo que la autenticación sea con estado (stateful).

Cómo funciona la "First-Party Session" con Sanctum:

  1. Tu SPA hace una solicitud GET a /sanctum/csrf-cookie. Laravel devuelve una cookie XSRF-TOKEN y establece la sesión.
  2. Tu SPA envía credenciales de inicio de sesión (usuario/contraseña) a tu endpoint de login (/api/login). El navegador incluye automáticamente la cookie XSRF-TOKEN y las cookies de sesión (porque es un dominio de primera parte).
  3. Laravel autentica al usuario y, si las credenciales son válidas, la sesión se activa y se crea una cookie de sesión que el navegador guardará y enviará automáticamente con cada solicitud subsiguiente.
  4. Para todas las solicitudes posteriores a endpoints protegidos por auth:sanctum desde esa misma SPA, el navegador enviará la cookie de sesión, y Sanctum la utilizará para autenticar al usuario. No se necesitan tokens explícitos en el encabezado Authorization para estas solicitudes.

En resumen:

  • First-Party Domain: El concepto de que tu frontend (SPA) y tu backend (API de Laravel) comparten el mismo dominio de nivel superior.
  • First-Party Session: El tipo de autenticación basada en cookies/sesiones que Laravel Sanctum activa cuando detecta que una solicitud proviene de un dominio que ha sido configurado como "first-party".

La interconexión es que el dominio de primera parte es una condición necesaria para que la autenticación de sesión de primera parte funcione en Sanctum.

Etiquetas:

Comentarios

Publicar un comentario

Entradas populares de este blog

Crear proyecto de frontend con Vite, React, Tailwind, Typescript y JSX

De
 ¿Cómo se crea un proyecto exclusivo de frontend con Vite, React, Tailwind, Typescript y JSX? ¡Absolutamente! Entiendo que quieres la guía completa para pasar de cero a tener un proyecto de frontend moderno, vacío y listo para ser llenado con tu código. A continuación, te proporciono un archivo de guía detallada que incluye todos los comandos necesarios para inicializar el proyecto, configurar Tailwind CSS, y los pasos clave para empezar a "poblarlo". Voy a generar un documento Markdown con la guía paso a paso, incluyendo los comandos de terminal y las modificaciones esenciales a los archivos de configuración. Guía: Creación de un Proyecto Frontend Puro (Vite, React, TypeScript, Tailwind) Este documento detalla el proceso para inicializar un proyecto de frontend vacío y optimizado, utilizando Vite como empaquetador, React como librería, TypeScript para tipado y Tailwind CSS para estilizado. 1. Inicialización del Proyecto con Vite Vite es la herramienta más rápida para emp...
Publicar un comentario
Leer más

Tokens V2

De
Tokens: Programme to discover tokens, where there are not. Now available at  https://puszcza.gnu.org.ua/projects/tokens/ This is Version 2, for  version 1, go here . Synopsis: use TokensV2; sub printFile; my @FORMAT = ( ['<Message Date=".*?" Time=".*?" DateTime=".*?" SessionID=".*?"><From>(?:<User FriendlyName=".*?"/>)+</From><To>(?:<User FriendlyName=".*?"/>)+</To><Text(?: Style=".*?")?>.*?</Text></Message>',   sub {     my $fh = $_[1];     my ($d, $t, $f, $s, $T) = $_[0] =~ m|<Message Date="(.*?)" Time="(.*?)" DateTime=".*?" SessionID=".*?">(<From>(?:<User FriendlyName=".*?"/>)+</From>)<To>(?:<User FriendlyName=".*?"/>)+</To><Text(?: Style="(.*?)")?>(.*?)</Text></Message>|;     my $F = join '<br />', ...
Publicar un comentario
Leer más

Perl Net::LDAP::SimpleServer

De
Adaptaciones sobre el módulo LDAP Server para Windows (Strawberry Perl) Lista de adaptaciones (continúa más abajo): - Relajación de condiciones de bind:     - Cuenta principal (principal account)     - Validación de contraseñas Ubicación del archivo: %Strawberry_Perl%\site\lib\net\ldap\SimpleServer\ProtocolHandler.pm CPAN: http://search.cpan.org/~russoz/Net-LDAP-SimpleServer-0.0.17/lib/Net/LDAP/SimpleServer.pm Código: package Net::LDAP::SimpleServer::ProtocolHandler; use strict; use warnings; # ABSTRACT: LDAP protocol handler used with Net::LDAP::SimpleServer our $VERSION = '0.0.17';    # VERSION use Net::LDAP::Server; use base 'Net::LDAP::Server'; use fields qw(store root_dn root_pw allow_anon); use Carp; use Net::LDAP::LDIF; use Net::LDAP::Util qw{canonical_dn}; use Net::LDAP::FilterMatch; use Net::LDAP::Constant (     qw/LDAP_SUCCESS LDAP_AUTH_UNKNOWN LDAP_INVALID_CREDENTIALS/,   ...
Publicar un comentario
Leer más