„Frontend React na Laravelu" niemal zawsze podnosi pytanie o uwierzytelnianie: osobne SPA z tokenami Sanctum czy wszystko w jednej aplikacji z Inertią i zwykłymi sesjami Laravela?
Oba modele są produkcyjne; rozwiązują różne kształty tego samego problemu. Oto jak wybrać, żeby nie żałować w szóstym miesiącu.
- Kontekst architektoniczny: Inertia.js z Laravel i React — SPA bez osobnego API.
Dwa modele, jeden diagram
Sesje Inertia.js. Strony React mieszkają w aplikacji Laravel. Logowanie to zwykły POST na trasę Laravela; przeglądarka dostaje ciasteczko sesyjne; każde kolejne żądanie Inertii niesie je automatycznie. Middleware, polityki i auth()->user() działają jak w Blade. Nigdzie nie ma tokenu.
Sanctum SPA. Aplikacja React jest wdrażana osobno (własna domena lub subdomena). Tryb stateful Sanctum uwierzytelnia ją ciasteczkami przez /sanctum/csrf-cookie i guard sesyjny — albo, dla klientów nieprzeglądarkowych, tokenami w nagłówku Authorization: Bearer.
| Aspekt | Sesje Inertia | Sanctum SPA (tokeny) |
|---|---|---|
| Gdzie żyje frontend | Ta sama aplikacja i repo | Osobna aplikacja i deploy |
| Poświadczenia | Ciasteczko sesyjne (HttpOnly) | Token w nagłówku (lub ciasteczko, tryb stateful) |
| CSRF | Automatyczny, same-origin | Trzeba podłączyć (/sanctum/csrf-cookie) |
| Wylogowanie / unieważnienie | Sesja unieważniana po stronie serwera | Usunięcie tokenu (per urządzenie) |
| Sesje na wielu urządzeniach | Sesja na przeglądarkę | Token na urządzenie — zaleta w mobile |
| Ekspozycja na XSS | Ciasteczka nie odczyta JS | Token czytelny, jeśli leży w localStorage |
| Koszt konfiguracji | Zero dodatkowej | CORS, cykl życia tokenów, obsługa odświeżania |
Co daje model tokenowy — i ile kosztuje
Tokeny są właściwą odpowiedzią, gdy backend konsumuje klient nieprzeglądarkowy: aplikacje mobilne, narzędzia desktopowe, integracje. Każde urządzenie ma własny token, unieważnianie działa per urządzenie, a API można później otworzyć dla partnerów. Koszty też są realne: utrzymujesz publiczny kontrakt — wersjonowanie, kształty odpowiedzi, formaty błędów — plus CORS i decyzje o przechowywaniu tokenów po stronie klienta.
Uwaga: Nigdy nie trzymaj tokenów w
localStorage, jeśli możesz tego uniknąć. Jeden XSS i token jest ukradziony. Dla pierwszoosobowych SPA używaj trybu stateful z ciasteczkami Sanctum; w mobile — bezpiecznego magazynu platformy.
Co daje model sesyjny Inertii
Zero instalacji wodno-kanalizacyjnej wokół auth. Logowanie, reset hasła, weryfikacja e-mail, 2FA — każdy przepis Laravela działa bez zmian, bo to zwykła aplikacja Laravel. Frontend nigdy nie widzi poświadczeń. W połączeniu z tokenami CSRF dołączanymi do żądań Inertii automatycznie, powierzchnia ataku to klasyczna, dobrze rozumiana powierzchnia Laravela — nie nowa, zaprojektowana w zeszłym tygodniu.
- Uczciwe ograniczenie: sesje obsługują dokładnie jednego klienta — aplikację webową. Aplikacja mobilna ich nie użyje.
Reguła decyzyjna, której używamy
- Tylko web, teraz i w przewidywalnej roadmapie → Inertia + sesje. Szybciej dostarczasz i mniej utrzymujesz.
- Mobile albo publiczne API w roadmapie na najbliższe miesiące → i tak zacznij od Inertii, ale tak ułóż kontrolery, by dało się wyciągnąć warstwę API (resources, form requesty, polityki — wszystko do ponownego użycia), a Sanctum dodaj, gdy drugi klient faktycznie się pojawi.
- Osobny zespół frontendowy z własnym cyklem wydań → Sanctum SPA z wersjonowanym API. Granica organizacyjna uzasadnia granicę techniczną.
Przedwczesne API to najdroższy sposób uwierzytelniania użytkowników, którzy o to nie prosili — ta sama logika co w Inertia.js czy Livewire, zastosowana do auth.
Ścieżka migracji (Inertia → +Sanctum)
Gdy przyjdzie drugi klient, nic nie idzie do kosza: kontrolery już zwracają resource'y, walidacja żyje w FormRequestach, autoryzacja w politykach. Dodajesz trasy API wołające tę samą logikę, instalujesz Sanctum, wystawiasz tokeny — a aplikacja Inertia dalej działa na sesjach równolegle. Robiliśmy taką ekstrakcję na produkcyjnych produktach; to dni pracy, nie przepisanie.
Planujesz aplikację, w której ta decyzja jest na horyzoncie?
Zobacz tworzenie aplikacji Laravel — projektujemy szwy z wyprzedzeniem.
FAQ
Czy sesje Inertia.js są bezpieczne bez tokenów?
Tak — to klasyczny model sesyjny Laravela: ciasteczka HttpOnly, CSRF, unieważnianie po stronie serwera. Dla aplikacji webowych bezpieczniejszy domyślny wybór niż tokeny w JS.
Kiedy naprawdę potrzebuję Sanctum?
Gdy klient żyje poza aplikacją Laravel: mobile, desktop, osobno wdrażany frontend albo publiczne API partnerskie.
Czy można zacząć od Inertii i dodać API później?
Tak — endpointy API za Sanctum wyciągasz, gdy pojawi się drugi klient; kontrolery, polityki i walidacja zostają ponownie użyte.
👉 Projektujesz uwierzytelnianie nowego produktu? Zobacz tworzenie aplikacji Laravel albo programista Laravel na zlecenie — model dobieramy pod roadmapę, nie pod nawyk.
📖 Czytaj dalej: Inertia.js z Laravel i React, Inertia.js czy Livewire i case study architektury OneCRMApp.