Uwierzytelnianie oparte na tokenie umożliwia użytkownikom uzyskanie tokena, który umożliwia im dostęp do usługi i/lub pobranie określonego zasobu bez używania nazwy użytkownika i hasła do uwierzytelniania każdego żądania. Ponieważ token może być samodzielną jednostką, która przekazuje wszystkie informacje wymagane do uwierzytelniania żądania, jest często określany jako uwierzytelnianie bezstanowe. W takim przypadku strona serwera nie musi utrzymywać stanu użytkownika.
Token uwierzytelniający jest tworzony przez usługę uwierzytelniającą i zawiera informacje umożliwiające identyfikację konkretnego użytkownika oraz ważność tokenu. Sam token jest podpisany kryptograficznie, aby zapobiec manipulacji.
Po walidacji tokena przez usługę, służy on do ustanowienia kontekstu bezpieczeństwa dla klienta. Dzięki czemu usługa może podejmować decyzje autoryzacyjne lub audytować aktywność dla kolejnych żądań użytkowników.
Typowe standardy uwierzytelniania opartego na tokenach obejmują tokeny internetowe JSON (JWT) i język SAML (Security Assertion Markup Language).
Plusy i minusy uwierzytelniania stanowego
Komunikacja stanowa przydaje się w przypadku wielu funkcji online. Są przypadki, w których chcielibyśmy, aby nasze stany zostały zapamiętane. Na przykład podczas zakupów online, gdy użytkownik umieści jeden przedmiot w swoim koszyku, nie chce, aby zniknął, gdy przejdzie na inną stronę.
Ale protokoły stanowe mają również swoje wady.
Skalowalność:
Najbardziej oczywistą wadą uwierzytelniania stanowego jest skalowalność. Aby śledzić dane sesji, każda utworzona sesja musi być utrzymywana gdzieś na serwerze. W systemie rozproszonym zajmuje jeszcze więcej miejsca na serwerze, ponieważ sesja jest współużytkowana przez wiele węzłów. Gdy potrzebne są dodatkowe serwery uwierzytelniające do obsługi wzrostu usług, użytkowników lub kopii zapasowych – te serwery muszą być zsynchronizowane
Synchronizowanie chmury z tożsamością lokalną:
Korzystanie z serwera uwierzytelniania stanowego oznacza, że tożsamości znajdują się teraz również w chmurze. Istnieją dwie tożsamości zarządzane przez dwa katalogi. Na przykład jeden przez Active Directory (on-premise) i jeden przez AzureAD (Cloud).
Konieczność zsynchronizowania tych tożsamości może spowodować rozrost tożsamości (Directory Sprawl). Rozrost tożsamości często pojawia się, gdy aplikacja/system nie jest lub nie może być zintegrowany z centralną usługą katalogową organizacji. Powoduje to konieczność zarządzania innym zestawem tożsamości użytkowników w celu wsparcia dostępu do tej aplikacji/systemu. Rozrost tożsamości był problemem dla organizacji, które przyjęły usługi w chmurze, które obsługują osobny silos tożsamości. Oznacza to, że użytkownicy potrzebowali oddzielnej tożsamości dla usługi w chmurze.
Czynnik bezpieczeństwa
Ponieważ komunikacja stanowa przechowuje poświadczenia logowania, istnieje ryzyko wycieku tych poświadczeń w wyniku ataków polegających na podsłuchiwaniu. Takie ataki to np. Man in the Middle (MITM) lub w wyniku naruszenia serwera uwierzytelniania.
Zalety chmury bezstanowego uwierzytelniania
Uwierzytelnianie bezstanowe rozwiązuje wiele wad uwierzytelniania stanowego.
Po pierwsze, serwery bezstanowe są nieskończenie łatwiejsze do skalowania, są używane jako brama i nie przechowują żadnych poświadczeń ani tożsamości, co ułatwia ich konfigurację. Nie przekazują synchronizacji z lokalnym dostawcą tożsamości (IDP), co eliminuje ryzyko rozrostu tożsamości.
Kolejna zaleta wynika z odpowiedzialności. Chmury stanowe zawierają poufne informacje (poświadczenia i tożsamości), które firmy, szczególnie z branży finansowej i opieki zdrowotnej, chciałyby zachować. Z punktu widzenia przepisów chmury bezstanowe są bardzo korzystne dla zapewnienia zgodności. Zaletą jest to, że informacje o poświadczeniach nigdy nie opuszczają lokalnego serwera.
Wykorzystanie wyłącznie lokalnych serwerów dostawcy tożsamości zanika wraz z nim. Wzmacniane są bezstanowe serwery w chmurze, wybór rozwiązania uwierzytelniania, które wykorzystuje bezstanową architekturę chmury, jest nie tylko bezpieczniejszą opcją, ale także sposobem na planowanie.
Bezstanowe, bezhasłowe podejście
Połączenie bezhasłowe i bezstanowe zmniejsza zagrożenia i koszty związane z poświadczeniami. Jednocześnie zapewniając bezpieczne przechowywanie tożsamości za środkami bezpieczeństwa lokalnego IDP.
CO TO JEST TOKEN SIECIOWY JSON?
JSON Web Token (JWT) to kompaktowy, bezpieczny dla adresów URL sposób reprezentowania oświadczeń, które mają być przesyłane między dwiema stronami. Oświadczenia w JWT są zakodowane jako obiekt JSON. Zawartość tokena może być podpisana cyfrowo, a następnie zweryfikowana przez odbiorcę. Sygnatury można stosować za pomocą klucza tajnego (za pomocą algorytmu HMAC) lub pary kluczy publiczny/prywatny za pomocą RSA lub ECDSA.
CZYM JEST ARCHITEKTURA BEZSTANOWA?
Architektura bezstanowa to koncepcja projektowania oprogramowania, w której każde żądanie od klienta do serwera musi zawierać wszystkie informacje niezbędne do zrozumienia żądania i nie może korzystać z żadnego kontekstu przechowywanego na serwerze. Stan sesji jest zatem utrzymywany w całości na kliencie. Natomiast klient jest odpowiedzialny za przechowywanie i obsługę wszystkich informacji związanych ze stanem aplikacji po stronie klienta. Oznacza to również, że klient jest odpowiedzialny za wysyłanie wszelkich informacji o stanie do serwera, kiedy tylko jest to potrzebne.
Aby umożliwić klientom dostęp do bezstanowych interfejsów API, konieczne jest, aby serwery zawierały po swojej stronie wszystkie informacje, których klient może potrzebować do utworzenia stanu. Obejmuje to również specyfikę uwierzytelniania/autoryzacji, które można spakować jako token i wysłać na serwer przy każdym żądaniu.
Innymi słowy, w architekturze bezstanowej każde żądanie jest samowystarczalne i może wystąpić w całkowitej izolacji od poprzednich lub przyszłych żądań.
JAKA JEST RÓŻNICA MIĘDZY STANOWĄ A BEZSTANOWĄ APLIKACJĄ W CHMURZE?
Aplikacja bezstanowa to taka, która nie zapisuje danych klienta wygenerowanych w jednej sesji do wykorzystania w następnej sesji — zamiast tego dane sesji są przechowywane na kliencie i w razie potrzeby przekazywane na serwer. Każda sesja jest przeprowadzana tak, jakby była to pierwsza sesja, a odpowiedzi nie są zależne od danych z poprzedniej sesji. Natomiast aplikacja stanowa zapisuje dane o każdej sesji klienta i używa tych danych przy następnym żądaniu klienta.
CZY DOWOLNY PROTOKÓŁ MOŻE BYĆ BEZSTANOWY (RESTAPI, LDAP, SAML)?
Aby protokół był bezstanowy, jego komunikujące się strony muszą obsługiwać architekturę bezstanową.
CO TO JEST UWIERZYTELNIANIE BEZSTANOWE?
Uwierzytelnianie oparte na tokenie umożliwia użytkownikom uzyskanie tokena, który umożliwia im dostęp do usługi i/lub pobranie określonego zasobu bez używania nazwy użytkownika i hasła do uwierzytelniania każdego żądania. Ponieważ token jest samodzielną jednostką, która przekazuje wszystkie informacje wymagane do uwierzytelnienia żądania, jest często określany jako uwierzytelnianie bezstanowe. Strona serwera nie musi utrzymywać stanu użytkownika.
CZY JAKIEKOLWIEK UWIERZYTELNIANIE OPARTE NA TOKENIE JEST BEZSTANOWE?
Uwierzytelnianie oparte na tokenach może służyć do włączania architektury bezstanowej, ale może być również używane w architekturach stanowych. Na przykład token JWT może zawierać wszystkie niezbędne dane sesji, zakodowane bezpośrednio w tokenie, w którym to przypadku obsługuje architekturę bezstanową. JWT może być również używany do prostego przechowywania odwołania lub identyfikatora sesji, w którym to przypadku dane sesji muszą być przechowywane po stronie serwera, dzięki czemu architektura jest stanowa.
