Szeroka Perspektywa Full-Stack Web Developmentu: Wprowadzenie do autoryzacji i uwierzytelnienia

0:00W tej lekcji wyjaśnię Ci na czym polega różnica pomiędzy autoryzacją oraz

0:04uwierzytelnienie użytkownika oraz zasadniczo jak przebiegają te procesy.

0:08Zacznijmy od tego, że użytkownik w momencie gdy loguje się do naszej

0:12aplikacji musi podać jakiś identyfikator, który jest unikatowy dla jego konta.

0:16Przykładem takiej informacji jest np.

0:18jego login, adres e-mail bądź np.

0:21numer telefonu.

0:22Następnie razem z taką informacją musi zostać dołączone hasło, bądź jakaś inna

0:26forma kodu, która umożliwi autoryzację tego użytkownika.

0:30Czyli nic innego jak po prostu sprawdzenie

0:32czy dany użytkownik istnieje w naszej bazie i czy podane przez niego hasło jest

0:37poprawne i też czy możemy go zalogować w naszym systemie.

0:41Proponuję, abyśmy przeszli sobie przez to

0:43raz jeszcze, aby wszystko było tutaj jasne.

0:45Zacznijmy od tego, że przede wszystkim nasz użytkownik musi znajdować się w

0:49naszej bazie danych, a to oznacza, że wcześniej musiał zostać zarejestrowany.

0:53Pomijamy ten proces ze względu na to, że jest on całkiem podobny, z tą różnicą, że

0:58w przeciwieństwie do logowania tworzone jest konto użytkownika.

1:01W każdym razie w momencie, gdy użytkownik

1:03przechodzi na stronę logowania, przesyła swój login oraz hasło, a na etapie

1:08backendu te informacje wykorzystywane są w celu odnalezienia tego konkretnego

1:12użytkownika oraz dodatkowo zweryfikowania, czy podane przez niego hasło pasuje do

1:17tego, które przechowywane jest w bazie danych.

1:20Jeżeli tak jest, to w przypadku gdy nasz

1:22backend wykorzystuje system w sesji, zostaje na serwerze utworzona właśnie

1:26sesja użytkownika, a następnie razem z odpowiedzią tzw.

1:30Session kuki, czyli nic innego jak ciasteczko, które trwa tak długo jak

1:34ustawiona jest sesja i umożliwia użytkownikowi wykonywanie kolejnych

1:39działań, przy czym te są już powiązane bezpośrednio z nim.

1:42Ponieważ to ciasteczko powiązane jest z

1:44sesją i co najwyżej backend musi się upewnić, czy ta sesja jest nadal aktywna.

1:49Jeżeli tak, to daje użytkownikowi dostęp do informacji, o które prosi.

1:54I teraz, jeżeli zastanawiasz się, na czym

1:56polega różnica pomiędzy autoryzacją a uwierzytelnienie, to autoryzacja jest to

2:00proces, do którego dochodzi w momencie logowania użytkownika.

2:04Czyli chodzi o upewnienie się, czy dane użytkownika, które podaje istnieją w

2:08naszym systemie i też czy możemy utworzyć dla niego w tym przypadku sesję.

2:12Jeżeli tak, połączenie jest autoryzowane i

2:15użytkownik zyskuje prawo dostępu do dalszych informacji w momencie, gdy

2:20wykonuje kolejne zapytania i w tym przypadku przesyłane jest ciasteczko, ta

2:24informacja zostaje wykorzystana w procesie uwierzytelnienia.

2:28Mianowicie może okazać się, że użytkownik

2:30poprawnie zaloguje się do naszego systemu, ale np.

2:33poprosi o informacje, do których dostępu mieć nie powinien.

2:36W takiej sytuacji proces uwierzytelnienia się nie powiedzie i użytkownik otrzyma

2:41informację o błędzie zawierającą powiadomienie, że oczywiście jego

2:45zapytanie zostało poprawnie zinterpretowane.

2:48Natomiast z różnych powodów nie może uzyskać dostępu do wskazanego zasobu.

2:53Idąc teraz dalej sytuacja nieco się

2:54zmienia w momencie, gdy mamy do czynienia z tokenem.

2:57Zwróć uwagę, że tutaj w przeciwieństwie do sesji, które były przechowywane po stronie

3:02serwera, tokeny przechowywane są po stronie klienta.

3:05Oznacza to, że w momencie logowania użytkownika, gdy faktycznie zostaje

3:09zweryfikowane, że istnieje także hasło jest poprawne.

3:12Zostaje wygenerowany dla niego tzw. token, np.

3:16Jamesa Web token, który zostaje przekazany w odpowiedzi.

3:19W takiej sytuacji po stronie klienta ten token musi zostać zapisany i być dołączany

3:24do każdego kolejnego zapytania w celu uzyskania dostępu.

3:27Tak długo jak ten token jest aktywny, użytkownik ma dostęp do naszej bazy.

3:32W momencie jednak ten token przestaje być

3:34aktywny, użytkownik ponownie musi się zalogować.

3:37W tym momencie być może zastanawiasz się,

3:39na czym polega różnica pomiędzy tokenem i sesjami.

3:42Otóż ta zasadnicza różnica, że sesje przechowywane są po stronie serwera, a

3:47tokeny po stronie klienta jest tutaj najbardziej kluczowa.

3:50Po prostu w momencie, gdy mamy do czynienia np.

3:53z wielo platform owymi aplikacjami, które wykorzystują API do tego, aby komunikować

3:58się często z wieloma serwerami, okazuje się, że znacznie lepszym pomysłem jest

4:02wykorzystanie tokenów, które po prostu przechowywane są po stronie klienta i

4:06zawierają niezbędne informacje do tego, aby określić, kto wykonuje dane zapytanie.

4:11Oznacza to mniej więcej tyle, że nawet jeżeli mielibyśmy tutaj dwa serwery, to

4:15niezależnie od tego, do którego trafi zapytanie, będą one w stanie precyzyjnie

4:20rozróżnić użytkownika i określić, czy ma dostęp do danego zasobu, czy też nie.

4:25W sytuacji jednak, gdy mamy do czynienia z

4:27sesjami, sesje te przechowywane są na serwerze.

4:30Oznacza to, że jeżeli tutaj mielibyśmy drugi serwer, to niestety on nie będzie

4:35posiadał informacji na temat sesji, która została utworzona na drugim serwerze.

4:40Naturalnie moglibyśmy utworzyć tutaj specjalną usługę służącą tylko do tego,

4:44aby przechowywać sesje i wtedy każdy z serwerów musi się z nią komunikować.

4:48Natomiast bez wątpienia jest to

4:50zdecydowanie trudniejsze rozwiązanie niż chociażby wykorzystanie tokena.

4:54Jednocześnie ta trudność pojawia się tylko

4:56w momencie, gdy mamy do czynienia z rozproszonymi.

5:00W momencie, gdy pracujemy z typowym front endem i back end.

5:04Całkiem dobrym pomysłem jest sięgnięcie po

5:05sesję ze względu na to, że jest to zdecydowanie prostsze niż np.

5:09wykorzystywanie tokenów.

5:11Oznacza to mniej więcej tyle, że w

5:12momencie, gdy tworzysz prostą aplikację, która zawiera wyłącznie frontend oraz

5:17backend, to zdecydowanie lepszym pomysłem jest wykorzystanie sesji.

5:21Jednak w momencie, gdy tworzysz usługę, która posiada API, które może być np.

5:25skalowane horyzontalnie na wiele różnych serwerów lub też masz jakiś inny konkretny

5:30powód mówiący o tym, że tokeny sprawdzą Ci się lepiej.

5:33Przykładem może być tutaj chociażby aplikacja mobilna.

5:36Od siebie dodam, że w większości

5:38przypadków spotykam się właśnie z systemami, które wykorzystują tokeny

5:41zamiast sesji i szczerze mówiąc sam coraz częściej z nich korzystam.

5:45Jednocześnie w momencie, gdy zagłębiałem

5:47się w tematy dotyczące kwestii bezpieczeństwa, no to okazuje się, że pod

5:51wieloma względami sesje są tutaj zdecydowanie lepszym wyborem.

5:55Szczególnie w momencie, gdy mamy do czynienia ze stosunkowo prostą aplikacją,

5:59w przypadku której nie do końca jest uzasadnione budowanie całego systemu

6:03obsługującego chociażby tokeny, które mogą zostać anulowane przez administratora.

6:08A to oznacza przygotowanie odpowiedniego mechanizmu, które pozwala na odrzucenie

6:12nawet poprawnego tokena w sytuacji, gdy ten znajduje się na takiej liście.

6:17Na koniec dnia jednak, gdy spojrzysz na to

6:19wszystko z boku, to jasno tutaj widać pewne podobieństwa.

6:23W jednym i drugim przypadku mamy formularz logowania.

6:26W jednym i drugim przypadku użytkownik jest weryfikowany pod kątem tego, czy

6:30znajduje się w bazie danych oraz tego, czy hasło, które podał jest poprawne.

6:34W momencie, gdy to się wydarzy, w jednym przypadku tworzona jest sesja na serwerze.

6:38W drugim przypadku generowany token, który musi zostać zapisany po stronie klienta.

6:43Następnie, niezależnie od mechanizmu, który został tutaj wybrany, informacja o

6:48danej sesji bądź też tokenu przesyłana jest z każdym kolejnym zapytaniem.

6:52To jak długo trwa dana sesja określona jest oczywiście w ustawieniach sesji, a to

6:57jak długo ważny jest token, skonfigurowany jest na etapie jego tworzenia.

7:02Oznacza to wszystko, że mamy tutaj po prostu do czynienia z dwoma różnymi

7:05strategiami do tego, aby osiągnąć zasadniczo to samo.

7:09Ale oczywiście, który sposób wybierzemy

7:11powinno być uzależnione od tego, jaki rodzaj aplikacji tworzymy oraz też który

7:16ze sposobów będzie dla nas bardziej użyteczny.

7:19I teraz na koniec proponuję, abyśmy

7:21jeszcze szybko przeszli sobie przez mechanizm przypominania hasła, ponieważ

7:25bardzo często występuje on właśnie na etapie, gdy użytkownik się loguje.

7:29Mianowicie formularz resetowania hasła zwykle wymaga od nas podania adresu email.

7:34Taki adres zostaje przekazany do backendu, gdzie oczywiście zostaje weryfikowane to,

7:38czy w ogóle taki użytkownik istnieje i jeżeli tak, zostaje wygenerowany dla niego

7:43specjalny token umożliwiający zresetowanie tego hasła.

7:47Token ten przesyłany jest zwykle za pomocą wiadomości email, gdzie zawarty jest link

7:52resetowania hasła, w ramach którego zawarty jest właśnie ten token.

7:56W momencie, gdy użytkownik wejdzie na ten adres, z parametru query string pobierany

8:01jest ten token, a następnie gdy użytkownik przejdzie na ten adres w momencie

8:06wysyłania zapytania, backend odczytuje ten parametr z query string, a następnie

8:10pobiera jego zawartość porównując go z zawartością przechowywaną w bazie danych.

8:15W momencie gdy token jest poprawny,

8:17wszystko się zgadza i hasło może zostać zresetowane.

8:20W przeciwnym razie prośba zostaje odrzucone.

8:23Oczywiście należy jeszcze zadbać o to, aby te tokeny były weryfikowane pod kątem nie

8:28tylko poprawności, ale również tego, czy są ważne.

8:31Mam tutaj na myśli chociażby flagę active, czyli po prostu oznaczenie czy token jest

8:35aktywny czy też nie lub też określanie tego na podstawie daty utworzenia np.

8:40po 10 minutach token może przestać być aktywny.

8:43No i w ten oto sposób wiesz już w jaki sposób działa autoryzacja oraz

8:47uwierzytelnienie użytkownika oraz nawet proces resetowania hasła.

8:51Te wszystkie informacje będą nam potrzebne

8:53na dalszym etapie i będziemy sobie do nich niejednokrotnie wracać.

8:57No może z wyjątkiem sesji, którą już nie będziemy się zajmować, ale w zamian

9:01mnóstwo naszej uwagi będzie poświęcona właśnie mechanizmowi Jameson Web Token.

9:06Zatem na ten moment dziękuję Ci za uwagę i do usłyszenia w kolejnym filmie.