Szeroka Perspektywa Full-Stack Web Developmentu: Rodzaje uwierzytelnienia

0:00Proponuję, abyśmy w tej lekcji skupili się

0:02nieco bardziej na mechanizmach autoryzacji oraz uwierzytelnienia użytkowników.

0:06Przejdziemy sobie przez te

0:07najpopularniejsze mechanizmy raz jeszcze, ale tym razem zwrócimy uwagę na szczegóły.

0:12W kolejnych lekcjach przyjrzymy się metodą implementacji.

0:16Jako pierwszy w kolejce jest BASIC.

0:18Jest to metoda, jak sama nazwa wskazuje, bardzo podstawowa, ale jednocześnie dość

0:23wystarczająca w przypadku, gdy potrzebujemy po prostu w najprostszy

0:27możliwy sposób zabezpieczyć dostęp do jakiegoś zasobu.

0:30W takiej sytuacji autoryzacja wygląda tak,

0:32że użytkownik musi podać swój login i hasło lub też po prostu przekazać nagłówek

0:37zawierający frazę basic, która sygnalizuje to, że mamy do czynienia właśnie z basenów

0:43oraz następnie musi podać w formie base64 swój login oraz hasło.

0:48I tutaj warto zaznaczyć, że jak pewnie

0:50wiesz base64 jest mechanizmem, który umożliwia nie do końca szyfrowanie, tylko

0:56po prostu zamiany naszego ciągu znaków na np.

0:59ciąg taki jaki mamy tutaj.

1:00Warto o tym pamiętać, że nie mamy tutaj do czynienia z szyfrowaniem.

1:04Ze względu na to, że po skopiowaniu tego

1:06ciągu znaków mogę po prostu wykonać metodę Base64 do tego, aby w moim schowku

1:12pojawiła się dokładnie fraza, która kryje się pod tym ciągiem znaków.

1:16Zatem z jednej strony trzeba uważać z

1:18takimi skanami ze względu na to, że w momencie gdy zostaną w jakikolwiek sposób

1:22przechwycone, to nie ma najmniejszego problemu, aby podejrzeć ich zawartość.

1:26W każdym razie, gdy przesyłamy taki nagłówek do serwera, jego zawartość jest

1:31tam odczytywane, a następnie porównywane np.

1:34z plikiem DOT i Anwilu lub też innym

1:36miejscem, w którym znajduje się właśnie te login oraz hasło użytkownika.

1:40Zwykle w tym przypadku raczej nie mówimy o

1:42sytuacji, w której mamy konta użytkowników, tylko po prostu jeden login

1:46oraz hasło, które w dość prosty sposób zabezpiecza dostęp do naszych zasobów.

1:50Oczywiście pamiętaj o tym, aby w tej

1:52sytuacji pod żadnym pozorem nie wykorzystywać nie szyfrowanego połączenia.

1:57Za każdym razem, aby zapewnić minimum

1:59bezpieczeństwa, musimy wykorzystać tutaj certyfikat SSL.

2:03I oczywiście na koniec dnia, w momencie, gdy dane przekazane razem w nagłówku

2:07zgadzają się z tym, co zostało zapisane w pliku, otrzymujemy naszą odpowiedź, bądź w

2:11przeciwnym razie status 401 mówiący o tym, że dostępu do zasobu nie mamy.

2:17Następnym i chyba najbardziej popularnym

2:19sposobem uwierzytelnienia połączenia jest wykorzystanie klucza API.

2:23Taki klucz może być przesłany albo w

2:25custom owym nagłówku, w przypadku którego konwersja często wskazuje nam na to, aby

2:30wykorzystać przedrostek x, a następnie epiki, bądź też dowolną inną nazwę.

2:35Czasem spotykamy tutaj nagłówek Auto Dizajn, a jeszcze w innym przypadku taki

2:39klucz API przesyłany jest bezpośrednio za pomocą Query.

2:43W każdym razie, niezależnie od tego, w jaki sposób przekażemy ten klucz API, to

2:47trafia on do serwera, a następnie zostaje wykorzystywany do tego, aby odnaleźć

2:52użytkownika, do którego ten klucz API należy.

2:55Zatem zwykle wygląda to tak, że w bazie

2:57danych albo bezpośrednio przy użytkowniku, albo w jakiejś oddzielnej tabeli

3:01przechowywana jest informacja o kluczach API przypisanych do użytkownika.

3:05Oczywiście to w jaki sposób przechowywane

3:07są te klucze zależy również od sposobu implementacji oraz też od tego, czy np.

3:12do danego klucza API nie ma przypisanych konkretnych grup uprawnień, bądź też np.

3:17termin wygaśnięcia.

3:18W każdym razie niezależnie od tego schemat działania jest następujący.

3:22Użytkownik w momencie, gdy posiada konto w

3:25jakimś serwisie, ma do swojej dyspozycji klucz API.

3:28Taki klucz API może być tylko jeden dla

3:30danego użytkownika, bądź też użytkownik może wygenerować ich kilka.

3:34No i następnie taki użytkownik musi zadbać o to, aby w momencie nawiązywania

3:38połączenia z serwerem identyfikować się właśnie z pomocą klucza API.

3:42Tego rodzaju uwierzytelnienie w porównaniu

3:44do baz AOW jest o tyle ciekawsze, że nie zawiera w sobie żadnych informacji.

3:49Jest to po prostu ciąg znaków, który

3:51został po stronie naszej bazy danych przypisany do użytkownika.

3:55W związku z tym, niezależnie od tego, kto

3:57próbuje go odczytać, tak naprawdę nie ma tutaj żadnej dodatkowej informacji.

4:01Z drugiej jednak strony, w momencie, gdy ktoś taki klucz przejmie,

4:04to może to być w zasadzie co tylko chce z takim kontem użytkownika.

4:08I z tego powodu ważne jest to, aby

4:10przynajmniej w jakiś sposób umożliwić użytkownikowi zablokowanie takiego klucza,

4:15który został narażony na ekspozycję także w temacie kluczy API.

4:19Myślę, że to tyle. Przechodzimy więc dalej do bardzo

4:22popularnego sposobu uwierzytelnienia, czyli tzw.

4:25off 2.0.

4:26W tym przypadku flow samej autoryzacji od

4:29uwierzytelnienia wygląda w taki sposób, że użytkownik przesyła login oraz hasło, a

4:33serwer weryfikuje te dane pod kątem tego czy są poprawne.

4:37W momencie gdy są, to identyfikator użytkownika zostaje zaszyfrowany w token.

4:41Przykładem takiego tokenu może być Jackson Web Token.

4:44Zatem sytuacja wygląda tak, że w momencie gdy wszystko jest tutaj poprawnie, serwer

4:49zwraca taki token do klienta, a klient musi ten token przechować.

4:53Ostatecznie jednak według mnie najlepszym

4:55z możliwych sposobów jest wykorzystanie HTTP only i póki co tutaj jest.

5:00Przez serwer, a następnie dołączany

5:02automatycznie przez przeglądarkę do każdego kolejnego połączenia.

5:06Oczywiście nie jest to norma i nadal w większości przypadków otrzymamy ten token

5:10w formie po prostu odpowiedzi, której zawartość musimy przechować po stronie

5:14klienta, a następnie przesyłać z każdym kolejnym zapytaniem.

5:18W związku z tym, że taki rodzaj komunikacji nie wykorzystuje stanu

5:21Staples, to za każdym razem w momencie, gdy wysyłamy zapytanie z takim tokenem,

5:26serwer posiada specjalny klucz, który weryfikuje poprawność tego tokenu, a

5:30następnie na jego podstawie przydziela nam dostęp do informacji lub też zwraca status

5:35401 informując nas o tym, że token nie jest poprawny.

5:39Co ciekawe, w tym przypadku możemy

5:41wykorzystać jeszcze jeden token i jest to tzw.

5:44token, który służy do tego, aby uzyskiwać access token bez konieczności ponownego

5:49logowania się i podawania hasła przez użytkownika.

5:52Sytuacja zmienia się wtedy w taki sposób,

5:54że w momencie logowania użytkownik otrzymuje access token, którego data

5:58wygaśnięcia jest stosunkowo krótka oraz dłuższy pod kątem ważności Refresh token.

6:04Jeden i drugi przechowywany jest po

6:06stronie klienta i w momencie, gdy Access token wygasa.

6:09W tej flash token wykorzystywany jest do

6:11tego, aby uzyskać nową parę bez konieczności podawania loginu oraz hasła.

6:15A tymczasem ostatnią formą uwierzytelnienia są klasyczne sesje, w

6:19przypadku których użytkownik po prostu loguje się swoim loginem oraz hasłem, a

6:24serwer po zweryfikowaniu tych informacji tworzy tzw.

6:27Session kuki.

6:28Dodatkowo informacje na temat tej sesji

6:30przechowywane są na tym konkretnym serwerze.

6:33Swoją drogą o tym już zdarzyło mi się tutaj mówić.

6:36W każdym razie w momencie, gdy połączenie zostanie poprawnie nawiązane wraz z

6:39odpowiedzią, po stronie przeglądarki zapisywane jest to Session kuki, a

6:43następnie dołączane do każdego kolejnego zapytania.

6:46I tutaj różnica pomiędzy tokenem a sesjami polega na tym, że sesje posiadają stan.

6:52Oznacza to, że dopiero w momencie albo wygaśnięcia sesji, albo w momencie

6:56wylogowania użytkownika sesja traci ważność.

6:59Dodatkowo też mamy tutaj ten element

7:02polegający na tym, że sesja przechowywana jest bezpośrednio na serwerze.

7:06Oznacza to, że jeżeli byśmy łączyli się z jakimś innym serwerem,

7:10to jak pewnie pamiętasz tej informacji o sesji nie byłoby na nim dostępnej.

7:15W związku z tym mielibyśmy tutaj problem z

7:17tym, żeby potwierdzić, że użytkownik wysyłający zapytanie jest faktycznie

7:21użytkownikiem logował się na tym pierwszym serwerze.

7:24Z tego powodu w przypadku bardziej

7:26rozproszonych serwerów zdecydowanie lepiej jest wykorzystać OAuth 2.0.

7:30Zatem to by było na tyle jeżeli chodzi o sposoby uwierzytelnienia połączenia.

7:35I raz jeszcze mamy tutaj BASIC, czyli

7:37przesłanie kodowanych danych logowania za pomocą nagłówka.

7:40Następnie mamy apki, czyli po prostu

7:42unikatowy dla użytkownika ciąg znaków, którego identyfikuje.

7:46I tak naprawdę każdy, kto posiada ten

7:48klucz API może korzystać z zasobów tego użytkownika.

7:51Następnie mamy 2.0, czyli obecnie drugi bardzo często wykorzystywany system

7:56uwierzytelnienia, polegający na wygenerowaniu np.

7:59tokena jw i przekazywaniu go w trakcie komunikacji poprzez http on i kuki.

8:04No i na samym końcu mamy sesję, czyli

8:06najbardziej klasyczny mechanizm uwierzytelnienia połączenia, które zwykle

8:10mogliśmy spotykać w bardziej klasycznych aplikacjach.

8:13Proponuję więc, abyśmy przyjrzeli się

8:15każdemu z tych sposobów, ale już od strony kodu.

8:18Zatem nie pozostaje mi nic innego, jak zaprosić Cię do kolejnej lekcji.