Opublikowano · Zaktualizowano
Sesja dla przeglądarki, tokeny dla aplikacji mobilnej
We własnych aplikacjach przeglądarkowych zwykle wybieram sesje i cookies. W wewnętrznej aplikacji mobilnej w Ionic i Capacitor postawiłem na access i refresh tokeny, bo zainstalowana aplikacja komunikuje się z backendem poza jakąkolwiek sesją przeglądarki.
- authentication
- sesje
- access token
- refresh token
- Laravel
- aplikacje mobilne
Aplikacje przeglądarkowe: sesje i cookies
Laravel ma już obsługę sesji po stronie serwera, cookies i ochronę CSRF dla requestów z przeglądarki. Jeśli aplikacja i klient przeglądarkowy należą do tego samego systemu, korzystam właśnie z tego.
Access i refresh tokeny oznaczałyby tam dodatkowy kod do wydawania, odnawiania i unieważniania tokenów, a w tych aplikacjach nie dawałyby nic ponad to, co zapewniała sesja.
Aplikacja mobilna: access i refresh tokeny
Z aplikacji korzystali w drukarni magazynierzy i operatorzy maszyn. Magazyn oznaczał rolki papieru rodzajem i marką, operatorzy zaznaczali, ile zostało z rolki (początek, środek albo koniec), a backend na tej podstawie śledził zużycie materiału i stan magazynu.
Wcześniej API działało na sesjach. Dla zainstalowanej aplikacji model zmieniono na access i refresh tokeny: backend wydaje aplikacji poświadczenia, zamiast utrzymywać dla niej sesję przeglądarkową. Cykl życia tokenów stał się częścią logowania w aplikacji mobilnej, a nie dodatkiem doklejonym do webowego flow opartego na cookies.
Jak wybieram
Dla każdego klienta sprawdzam, gdzie można trzymać poświadczenia, jak wygasa dostęp i jak można go odebrać. W tych projektach wyszły z tego sesje oparte na cookies dla przeglądarek oraz access i refresh tokeny dla zainstalowanej aplikacji.