wprowadzenie
uwierzytelnianie oparte na tokenach jest obecnie widoczne w całym Internecie. W przypadku większości firm internetowych korzystających z interfejsu API tokeny są najlepszym sposobem obsługi uwierzytelniania dla wielu użytkowników.
istnieje kilka bardzo ważnych czynników przy wyborze uwierzytelniania opartego na tokenach dla Twojej aplikacji. Główne powody tokenów to:
- bezstanowe i skalowalne serwery
- gotowe aplikacje mobilne
- przekaż uwierzytelnianie do innych aplikacji
- dodatkowe bezpieczeństwo
kto używa uwierzytelniania opartego na tokenach?
każdy większy interfejs API lub aplikacja internetowa, na którą się natknąłeś, ma najprawdopodobniej używane tokeny. Aplikacje takie jak Facebook, Twitter, Google+, GitHub i wiele innych używają tokenów.
przyjrzyjmy się dokładnie, jak to działa.
dlaczego pojawiły się tokeny
zanim dowiemy się, jak działa uwierzytelnianie oparte na tokenach i jakie są jego zalety, musimy przyjrzeć się sposobowi uwierzytelniania w przeszłości.
uwierzytelnianie oparte na serwerze (metoda tradycyjna)
Ponieważ protokół HTTP jest bezstanowy, oznacza to, że jeśli uwierzytelnimy użytkownika za pomocą nazwy użytkownika i hasła, to na następnym żądaniu nasza aplikacja nie będzie wiedziała, kim jesteśmy. Musielibyśmy ponownie uwierzytelnić.
tradycyjnym sposobem, aby nasze aplikacje pamiętały kim jesteśmy, jest przechowywanie informacji o zalogowanym użytkowniku na serwerze. Można to zrobić na kilka różnych sposobów na sesji, zwykle w pamięci lub zapisane na dysku.
wraz z rozwojem sieci, aplikacji i aplikacji mobilnych ta metoda uwierzytelniania wykazała problemy, zwłaszcza w skalowalności.
problemy z uwierzytelnianiem opartym na serwerze
z tą metodą uwierzytelniania pojawiło się kilka poważnych problemów.
- : Za każdym razem, gdy użytkownik jest uwierzytelniany, serwer będzie musiał utworzyć rekord gdzieś na naszym serwerze. Zwykle odbywa się to w pamięci, a gdy jest wielu użytkowników uwierzytelniających, narzut na serwer wzrasta.
- skalowalność: ponieważ sesje są przechowywane w pamięci, stwarza to problemy ze skalowalnością. Ponieważ nasi dostawcy usług w chmurze zaczynają replikować serwery w celu obsługi obciążenia aplikacji, posiadanie ważnych informacji w pamięci sesji ograniczy naszą zdolność do skalowania.
- Kors: Ponieważ chcemy rozszerzyć naszą aplikację, aby umożliwić korzystanie z naszych danych na wielu urządzeniach mobilnych, musimy martwić się o udostępnianie zasobów cross-origin (CORS). Podczas korzystania z połączeń AJAX do pobierania zasobów z innej domeny (mobilnej do naszego serwera API), możemy napotkać problemy z zakazanymi żądaniami.
- CSRF: będziemy mieć również ochronę przed fałszowaniem żądań między witrynami (CSRF). Użytkownicy są podatni na ataki CSRF, ponieważ mogą być już uwierzytelnieni za pomocą powiedzmy strony bankowej i można to wykorzystać podczas odwiedzania innych witryn.
z tymi problemami, skalowalność jest głównym, warto było spróbować innego podejścia.
jak działa uwierzytelnianie oparte na tokenach
uwierzytelnianie oparte na tokenach jest bezstanowe. Nie przechowujemy żadnych informacji o naszym użytkowniku na serwerze ani w sesji.
sama ta koncepcja rozwiązuje wiele problemów związanych z przechowywaniem informacji na serwerze.
Brak informacji o sesji oznacza, że aplikacja może skalować i dodawać więcej maszyn w razie potrzeby, nie martwiąc się o to, gdzie użytkownik jest zalogowany.
chociaż ta implementacja może się różnić, jej istota jest następująca:
- użytkownik żąda dostępu za pomocą nazwy użytkownika / hasła
- aplikacja weryfikuje poświadczenia
- aplikacja dostarcza klientowi podpisany token
- Klient przechowuje ten token i wysyła go wraz z każdym żądaniem
- Serwer weryfikuje token i odpowiada danymi
każde żądanie będzie wymagało tokena. Token ten powinien być wysłany w nagłówku HTTP, abyśmy trzymali się idei bezstanowych żądań HTTP. Będziemy również musieli ustawić nasz serwer tak, aby akceptował żądania ze wszystkich domen używając Access-Control-Allow-Origin: *. Co jest interesujące w oznaczaniu * w nagłówku ACAO, to to, że nie pozwala żądaniom na dostarczanie poświadczeń, takich jak uwierzytelnianie HTTP, certyfikaty SSL po stronie klienta lub pliki cookie.
gdy już uwierzytelnimy się za pomocą naszych informacji i posiadamy nasz token, jesteśmy w stanie zrobić wiele rzeczy za pomocą tego tokena.
możemy nawet utworzyć token oparty na uprawnieniach i przekazać go do aplikacji innej firmy (powiedzmy nowej aplikacji mobilnej, której chcemy użyć), a oni będą mogli mieć dostęp do naszych danych-ale tylko do informacji, które pozwoliliśmy za pomocą tego konkretnego tokena.
zalety tokenów
bezstanowe i skalowalne
tokeny są przechowywane po stronie klienta. Całkowicie bezpaństwowy i gotowy do skalowania. Nasze load balancers są w stanie przekazać użytkownika na dowolny z naszych serwerów, ponieważ nigdzie nie ma informacji o stanie lub sesji.
gdybyśmy mieli zachować informacje o sesji użytkownika, który był zalogowany, wymagałoby to wysyłania tego użytkownika do tego samego serwera, na którym się zalogował (zwanego powinowactwem sesji).
to przynosi problemy, ponieważ niektórzy użytkownicy będą zmuszeni do tego samego serwera, co może spowodować duży ruch.
nie martw się! Problemy te zniknęły z tokenami, ponieważ sam token przechowuje dane dla tego użytkownika.
bezpieczeństwo
token, a nie plik cookie, jest wysyłany na każde żądanie, a ponieważ nie jest wysyłany plik cookie, pomaga to zapobiegać atakom CSRF. Nawet jeśli konkretna implementacja przechowuje token w pliku cookie po stronie klienta, plik cookie jest jedynie mechanizmem przechowywania, a nie mechanizmem uwierzytelniania. Nie ma informacji opartych na sesji do manipulowania, ponieważ nie mamy sesji!
token wygasa również po określonym czasie, więc użytkownik będzie musiał zalogować się ponownie. To pomaga nam zachować bezpieczeństwo. Istnieje również koncepcja odwołania tokenu, która pozwala nam unieważnić konkretny token, a nawet grupę tokenów w oparciu o ten sam grant autoryzacyjny.
rozszerzalność (przyjaciel znajomego i uprawnienia)
tokeny pozwolą nam budować aplikacje, które dzielą uprawnienia z innymi. Na przykład połączyliśmy losowe konta społecznościowe z naszymi głównymi, takimi jak Facebook lub Twitter.
kiedy logujemy się do Twittera za pośrednictwem usługi (powiedzmy bufora), pozwalamy Bufferowi publikować na naszym strumieniu na Twitterze.
korzystając z tokenów, w ten sposób zapewniamy selektywne uprawnienia aplikacjom innych firm. Mogliśmy nawet zbudować własne API i rozdać specjalne tokeny uprawnień, jeśli nasi użytkownicy chcieli dać dostęp do swoich danych innej aplikacji.
wiele platform i domen
rozmawialiśmy trochę o CORS wcześniej. Kiedy nasza aplikacja i usługa się rozszerzy, będziemy musieli zapewnić dostęp do wszelkiego rodzaju urządzeń i aplikacji (ponieważ nasza aplikacja z pewnością stanie się popularna!).
mając nasze API tylko do obsługi danych, możemy również dokonać wyboru projektu do obsługi zasobów z CDN. Eliminuje to problemy, które wywołuje CORS po ustawieniu szybkiej konfiguracji nagłówka dla naszej aplikacji.
Access-Control-Allow-Origin: *nasze dane i zasoby są teraz dostępne dla żądań z dowolnej domeny, o ile Użytkownik ma ważny token.
oparte na standardach
podczas tworzenia tokenu masz kilka opcji. Będziemy nurkować bardziej w tym temacie, gdy zabezpieczymy API w kolejnym artykule, ale standardem do użycia będą JSON Web Tokens.
ten poręczny debugger i wykres bibliotek pokazuje wsparcie dla tokenów internetowych JSON. Możesz zobaczyć, że ma dużą ilość wsparcia w różnych językach. Oznacza to, że możesz wyłączyć mechanizm uwierzytelniania, jeśli zdecydujesz się to zrobić w przyszłości!
podsumowanie
to było tylko spojrzenie na to, jak i dlaczego uwierzytelnianie oparte na tokenie. Jak to zawsze ma miejsce w świecie bezpieczeństwa, każdy temat ma znacznie więcej i różni się w zależności od przypadku użycia. Zagłębiliśmy się nawet w niektóre tematy dotyczące skalowalności, które również zasługują na własną rozmowę.
to był szybki przegląd na wysokim poziomie, więc proszę zwrócić uwagę na wszystko, co zostało pominięte lub na jakiekolwiek pytania w tej sprawie.
w następnym artykule przyjrzymy się anatomii tokenów internetowych JSON.
Uwaga: dodanie informacji o nagłówku ACAO i wyjaśnień CSRF (dzięki Emily Stark za informacje o artykule)