Jeśli chodzi o uwierzytelnianie w Laravel, istnieje wiele opcji. Ale czego powinniśmy użyć, jeśli chodzi o uwierzytelnianie API?
Tradycyjnie opieralibyśmy się na czymś takim jak tokeny internetowe JSON do uwierzytelniania API, podobnie jak uwierzytelnianie oparte na sesji dla sieci. Zamieniasz swoje dane uwierzytelniające na coś, co zapewni Ci dłuższy dostęp.
Następnie zaczęliśmy używać Laravel Passport, fantastycznej implementacji OAuth, której można użyć do zapewnienia dostępu OAuth do aplikacji Laravel, niezależnie od tego, czy jest to uwierzytelnianie między serwerami, uwierzytelnianie mobilne czy inne rodzaje uwierzytelniania. Przez długi czas trzymaliśmy się korzystania z paszportu Laravel i typu Password Grant, które pozwalały nam wysyłać nasze dane uwierzytelniające wraz ze szczegółami aplikacji OAuth, a my odzyskiwaliśmy token dostępu i odświeżania - umożliwiając nam dostęp i sposób na odświeżenie tego dostępu po jego wygaśnięciu. Nie jest to jednak już zalecane jako mechanizm uwierzytelniania, tak jak kiedyś go używaliśmy.
Dokąd nas to prowadzi? Czy Sanctum jest jedyną zalecaną opcją? Cóż, i tak, i nie. Sanctum zostało zaprojektowane jako lekka alternatywa dla Passporta, ale w rzeczywistości osiągnęło znacznie więcej. Niezależnie od tego, czy budujesz aplikację internetową, implementację klienta, czy cokolwiek pośredniego - sanctum szybko stało się złotym standardem uwierzytelniania w ekosystemie Laravel.
Co to jednak oznacza dla interfejsów API? Czy musimy przekazywać nazwę tokena za każdym razem, gdy chcemy się uwierzytelnić? Cóż, możesz to zrobić - nikomu to nie zaszkodzi. Jak jednak uwierzytelnić moje interfejsy API w Laravel?
Przejdźmy przez moje podejście i zobaczmy, dlaczego to działa/ma sens. Zaczyna się od poświadczeń użytkowników - jak każdy odpowiedni mechanizm uwierzytelniania. Wysyłamy je do naszych punktów końcowych logowania lub rejestracji - a Laravel robi dla nas magię (w zależności od pakietu, którego używamy).
Załóżmy, że używamy Laravel Breeze lub Jetstream. W takim przypadku dostarczone uwierzytelnianie utworzy dla nas plik cookie oparty na sesji, który nasza implementacja może następnie wykorzystać do każdego kolejnego żądania w celu udowodnienia jego uwierzytelnionego stanu. Trochę mnie to zdezorientowało. Zastanawiałem się, gdzie powinien być mój token i co mam po swojej stronie, aby udowodnić, że jestem uwierzytelniony inny niż plik cookie. Byłem tak przyzwyczajony do radzenia sobie z tym żetonem lub tym żetonem, że byłem w stanie go użyć, aby udowodnić moją tożsamość. Ciasteczka były dla sieci, prawda? Nie postrzegałem mojego API jako internetowego interfejsu API, co pokazuje, że wszyscy czasami możemy być nieco naiwni.
Załóżmy, że tworzę aplikację CLI, aplikację mobilną lub integrację, która musi działać z moim lokalnym systemem jako coś instalowalnego. W takim przypadku możemy użyć Sanctum, aby przekazać nazwę, aby utworzyć token, który wymaga przechowywania - co wydaje się naturalne. Nasze API może jednak mieć integrację za pośrednictwem aplikacji Single Page - lub nawet innej aplikacji również zbudowanej w Laravel. Ta część nie ma znaczenia, ponieważ nie jest to coś, co instalujemy.
Najlepszym sposobem podejścia do uwierzytelniania jest postępowanie zgodnie z tym, co nazwałbym prostym przewodnikiem:
budujesz coś, do czego można uzyskać dostęp, a nie zainstalować. W takiej sytuacji należy użyć Laravel Sanctum z uwierzytelnianiem opartym na plikach cookie. Plik cookie można skonfigurować tak, aby był tak długi lub krótkotrwały, jak wymaga tego dostęp, a po zatrzymaniu dostępu uwierzytelnianie może również działać.
Tworzysz coś, co jest zainstalowane na urządzeniu użytkownika. W tym miejscu musimy dokonać kilku wyborów. Czy dostęp jest czymś, co musi być kontrolowane na podstawie tożsamości? Innymi słowy - czy aplikacja ma dostęp do wszystkiego, a nie ma warstwy autoryzacji? Laravel Passport przy użyciu poświadczeń klienta jest dobrym połączeniem, jeśli tak jest. Laravel Passport ma typ dotacji o nazwie Client Credentials: gdzie uwierzytelniasz klienta, a nie użytkownika - więc każdy, kto ma dostęp do klienta, może kontrolować system. Możesz pójść nieco dalej z PKCE, gdzie nie możesz zagwarantować poufności tajemnicy klienta.
Jeśli chcesz uwierzytelnić użytkownika, a nie klienta - oprzyj się na Laravel Sanctum i przekaż unikalną nazwę zainstalowanej aplikacji - abyś mógł przechowywać dostarczony token i używać go wielokrotnie.
Największym problemem związanym z używaniem Laravel Sanctum jest to, że musisz pobrać plik cookie żądania między witrynami, aby wysyłać żądania do interfejsu API Laravel. Podczas tworzenia SPA nie stanowi to problemu i jest lepszym podejściem niż przechowywanie tokenu internetowego JSON w magazynie lokalnym.
