Co to jest uwierzytelnianie oparte na tokenach?


Odpowiedzi:


543

Myślę, że dobrze to tutaj wyjaśniono - cytując tylko kluczowe zdania długiego artykułu:

Ogólna koncepcja systemu uwierzytelniania opartego na tokenach jest prosta. Zezwalaj użytkownikom na wpisanie nazwy użytkownika i hasła w celu uzyskania tokena, który pozwala im pobrać określony zasób - bez użycia nazwy użytkownika i hasła. Po uzyskaniu tokena użytkownik może zaoferować token - który zapewnia dostęp do określonego zasobu przez pewien czas - zdalnej stronie.

Innymi słowy: dodaj jeden poziom pośredni do uwierzytelnienia - zamiast konieczności uwierzytelniania za pomocą nazwy użytkownika i hasła dla każdego chronionego zasobu, użytkownik uwierzytelnia się w ten sposób jeden raz (w ramach sesji o ograniczonym czasie trwania), w zamian uzyskuje token ograniczony czasowo i używa tego tokena do dalszego uwierzytelniania podczas sesji.

Zalet jest wiele - np. Użytkownik może przekazać token, gdy już go zdobędzie, na inny automatyczny system, któremu chce zaufać przez ograniczony czas i ograniczony zestaw zasobów, ale nie byłby skłonny zaufać swoją nazwą użytkownika i hasłem (tj. każdym zasobem, do którego mają dostęp, na zawsze lub przynajmniej do czasu zmiany hasła).

Jeśli coś jest nadal niejasne, edytuj swoje pytanie, aby wyjaśnić, CO NIE jest dla Ciebie w 100% jasne i jestem pewien, że możemy Ci pomóc dalej.


6
Czy mam rację sądząc, że w aplikacji internetowej jeden (lub więcej) plików cookie ze zdalnej strony internetowej pełni funkcję tokena?
AJP,

29
Ponieważ tokeny są przechowywane jako pliki cookie, czy istnieje coś, co powstrzyma osobę przed kradzieżą tego pliku cookie / tokenem i samodzielnym użyciem go, oszukując serwer, aby pomyślał, że jest autoryzowanym użytkownikiem? Oczywiście mogli go używać tylko przez x czasu, ale w tym czasie mogli wyrządzić wszystkie szkody, których potrzebowali.
BenM,

40
Czym różni się to od SessionAuthentication, w której użytkownik może uzyskać identyfikator_sesji, wprowadzając swoją nazwę użytkownika i hasło, a następnie wykorzystuje ten identyfikator_sesji w kolejnym żądaniu?
Saurabh Verma

4
jeśli token wygaśnie, czy użytkownik musi się ponownie zalogować, aby uzyskać nowy token?
Anthony Do

12
@SaurabhVerma różni się od sesji, ponieważ nie musisz przechowywać informacji w pliku cookie. Jest to świetne rozwiązanie na urządzenia mobilne, z których niektóre mają ograniczenia dotyczące używania plików cookie.
Kebman

182

Od Auth0.com

Uwierzytelnianie oparte na tokenach polega na podpisanym tokenie, który jest wysyłany do serwera przy każdym żądaniu.

Jakie są zalety korzystania z podejścia opartego na tokenach?

  • Cross-domain / CORS: pliki cookie + CORS nie działają dobrze w różnych domenach. Podejście oparte na tokenach umożliwia wykonywanie połączeń AJAX do dowolnego serwera w dowolnej domenie, ponieważ do przesyłania informacji o użytkownikach używa się nagłówka HTTP.

  • Bezstanowy (inaczej skalowalność po stronie serwera): nie ma potrzeby utrzymywania magazynu sesji, token jest niezależną jednostką, która przekazuje wszystkie informacje o użytkowniku. Reszta stanu mieszka w plikach cookie lub lokalnym magazynie po stronie klienta.

  • CDN: możesz obsługiwać wszystkie zasoby aplikacji z CDN (np. Javascript, HTML, obrazy itp.), A strona serwera to tylko interfejs API.

  • Oddzielenie: nie jesteś powiązany z żadnym konkretnym schematem uwierzytelniania. Token może być generowany w dowolnym miejscu, dlatego interfejs API można wywołać z dowolnego miejsca za pomocą jednego sposobu uwierzytelnienia tych połączeń.

  • Gotowy na urządzenia mobilne: kiedy zaczynasz pracę na natywnej platformie (iOS, Android, Windows 8 itp.), Pliki cookie nie są idealne, gdy korzystanie z tokena znacznie upraszcza.

  • CSRF: ponieważ nie korzystasz z plików cookie, nie musisz chronić się przed żądaniami pochodzącymi z różnych witryn (np. Nie byłoby możliwe przesłanie witryny do witryny, wygenerowanie żądania POST i ponowne użycie istniejącego pliku cookie uwierzytelniania, ponieważ nie będzie ).

  • Wydajność: nie przedstawiamy tutaj żadnych testów wydajności, ale obieg sieci (np. Znalezienie sesji w bazie danych) prawdopodobnie zajmie więcej czasu niż obliczenie HMACSHA256 w celu sprawdzenia tokena i przeanalizowania jego zawartości.


6
@Asik Wszystkie punkty tutaj są ważne oprócz „Bezstanowego”, gdy zaczynasz zajmować się
cofaniem

Cytowana strona poleca nowszy artykuł na ten sam temat: auth0.com/blog/cookies-vs-tokens-definitive-guide
ASalazar

2
Możesz przeczytać „Przestań używać JWT do sesji”: cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions
Juraj Martinka

1
Asik, co powiesz na ważność tokena i kiedy wygasa? Jeśli dodasz te informacje, byłoby dobrze.
Arun Prakash

2
Link jest teraz zepsuty.
Eliptyczny widok

95

A tokento fragment danych, który Server Xmógł zostać utworzony i który zawiera wystarczającą ilość danych do zidentyfikowania konkretnego użytkownika.

Możesz przedstawić swoje dane logowania i poprosić Server Xo token; a następnie możesz przedstawić swój tokeni poprosić Server Xo wykonanie czynności specyficznej dla użytkownika.

TokenSą tworzone przy użyciu różnych kombinacji różnych technik z dziedziny kryptografii, a także z wkładem z szerszego zakresu badań nad bezpieczeństwem. Jeśli zdecydujesz się stworzyć własny tokensystem, najlepiej bądź naprawdę mądry.


4
Ogólnie rzecz biorąc, jeśli chcesz uwierzytelniania opartego na tokenach, powinieneś zacząć od OAuth.
Bob Aman,

6
OAuth jest z pewnością wykonalny w aplikacji internetowej. Ale na przykład sesje logowania do systemu operacyjnego również korzystają z systemów tokenów, podobnie jak wiele innych programów, więc pomysł ten nie ogranicza się do sieci.
yfeldblum

1
Token jest prawdopodobnie również preferowany w niepublicznym systemie obsługi klienta. Firma kontroluje nazwę użytkownika / hasło oraz wydaje i kontroluje token.
KevinManx

chrs - ale czym różni się ten system od systemu opartego na sesjach?
BKSpurgeon

@BKSpurgeon - Tokeny są powszechnym sposobem implementacji uwierzytelnionych sesji.
yfeldblum

40

Token to kawałek danych tworzony przez serwer i zawiera informacje identyfikujące konkretnego użytkownika i ważność tokena. Token będzie zawierał informacje o użytkowniku, a także specjalny kod tokena, który użytkownik może przekazać do serwera za pomocą każdej metody obsługującej uwierzytelnianie, zamiast bezpośredniego przekazywania nazwy użytkownika i hasła.

Uwierzytelnianie oparte na tokenach to technika zabezpieczeń, która uwierzytelnia użytkowników, którzy próbują zalogować się do serwera, sieci lub innego bezpiecznego systemu, przy użyciu tokena zabezpieczającego dostarczonego przez serwer.

Uwierzytelnianie kończy się powodzeniem, jeśli użytkownik może udowodnić serwerowi, że jest prawidłowym użytkownikiem, przekazując token zabezpieczający. Usługa sprawdza poprawność tokena zabezpieczającego i przetwarza żądanie użytkownika.

Po sprawdzeniu poprawności 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ć kolejne żądania użytkownika.

odwiedź źródło


22

Na podstawie tokena (bezpieczeństwo / uwierzytelnianie)

oznacza, że ​​aby udowodnić, że mamy dostęp, najpierw musimy otrzymać token. W prawdziwym scenariuszu żeton może być kartą dostępu do budynku, kluczem do zamka w twoim domu. Aby odzyskać kartę kluczową do biura lub klucz do domu, musisz najpierw udowodnić, kim jesteś, i że faktycznie masz dostęp do tego tokena. Może to być coś tak prostego, jak pokazanie komuś swojego identyfikatora lub podanie tajnego hasła. Wyobraź sobie, że muszę uzyskać dostęp do mojego biura. Schodzę do biura ochrony, pokazuję im swój dowód tożsamości, a oni dają mi ten token, który wpuszcza mnie do budynku. Teraz mam nieograniczony dostęp do robienia wszystkiego, co chcę w budynku, o ile mam ze sobą swój token.

Jaka jest korzyść z bezpieczeństwa opartego na tokenach?

Jeśli przypomnimy sobie niepewny interfejs API, musieliśmy w takim przypadku podać hasło do wszystkiego, co chcieliśmy zrobić.

Wyobrażać sobieże za każdym razem, gdy wchodzimy do drzwi w naszym biurze, musimy dać każdemu siedzącemu przy drzwiach nasze hasło. To byłoby całkiem złe, ponieważ oznacza to, że każdy w naszym biurze może wziąć nasze hasło i podszyć się pod nas, a to bardzo źle. Zamiast tego pobieramy token, oczywiście wraz z hasłem, ale pobieramy go od jednej osoby. Następnie możemy użyć tego tokena w dowolnym miejscu wewnątrz budynku. Oczywiście, jeśli zgubimy token, mamy ten sam problem, jakby ktoś inny znał nasze hasło, ale prowadzi nas to do tego, w jaki sposób upewniamy się, że jeśli stracimy token, możemy cofnąć dostęp, a może token nie powinniśmy żyć dłużej niż 24 godziny, więc następnego dnia, kiedy przyjedziemy do biura, musimy ponownie okazać dowód tożsamości. Ale wciąż jest tylko jedna osoba, której pokazujemy identyfikator,


15

Pytanie jest stare, a technologia się rozwinęła, oto obecny stan:

JSON Web Token (JWT) to otwarty standard oparty na JSON (RFC 7519) do przekazywania roszczeń między stronami w środowisku aplikacji WWW. Tokeny są zaprojektowane tak, aby były zwarte, bezpieczne pod adresem URL i nadawały się do użytku, zwłaszcza w kontekście pojedynczego logowania w przeglądarce internetowej.

https://en.wikipedia.org/wiki/JSON_Web_Token


1
Nie sądzę, że JWT reprezentuje obecny stan technologii wdrażania uwierzytelniania opartego na tokenach. Jest to tylko jeden sposób na wdrożenie i wiele wad, które wymownie przedstawiają artykuły, takie jak cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions
Sung Cho

3

To tylko skrót, który jest powiązany z użytkownikiem w bazie danych lub w inny sposób. Tego tokena można użyć do uwierzytelnienia, a następnie autoryzacji zawartości aplikacji związanej z dostępem użytkownika. Aby pobrać ten token po stronie klienta, wymagany jest login. Po pierwszym logowaniu musisz zapisać pobrany token, a nie inne dane, takie jak sesja, identyfikator sesji, ponieważ tutaj wszystko jest tokenem, aby uzyskać dostęp do innych zasobów aplikacji.

Token służy do zapewnienia autentyczności użytkownika.


3

Najbardziej preferowanym obecnie sposobem zabezpieczenia zasobów Web API jest uwierzytelnianie użytkowników na serwerze Web API za pomocą podpisanego tokena (który zawiera wystarczającą ilość informacji, aby zidentyfikować konkretnego użytkownika), który musi być wysyłany do serwera przez klienta z każdym i każda prośba. Nazywa się to podejściem opartym na tokenach.

Uwierzytelnianie oparte na tokenach działa w następujący sposób:

Użytkownik wprowadza nazwę i hasło do klienta (klient oznacza przeglądarkę lub urządzenia mobilne itp.).

Następnie klient wysyła te poświadczenia (tj. Nazwę użytkownika i hasło) do serwera autoryzacji.

Następnie serwer autoryzacji uwierzytelnia poświadczenia klienta (tj. Nazwę użytkownika i hasło), a następnie generuje i zwraca token dostępu. Ten token dostępu zawiera wystarczającą ilość informacji, aby zidentyfikować użytkownika, a także czas wygaśnięcia tokena.

Aplikacja kliencka następnie dołącza token dostępu do nagłówka autoryzacji żądania HTTP, aby uzyskać dostęp do ograniczonych zasobów z serwera zasobów do momentu wygaśnięcia tokena.

Poniższy artykuł pokazuje, jak krok po kroku wdrożyć uwierzytelnianie oparte na tokenie w interfejsie API WEB.

https://dotnettutorials.net/lesson/token-based-authentication-web-api/


-2

Po zarejestrowaniu się w nowej witrynie internetowej często wysyłany jest e-mail w celu aktywacji konta. Ten e-mail zazwyczaj zawiera link do kliknięcia. Część tego linku zawiera token, serwer wie o tym tokenie i może go powiązać z twoim kontem. Token zwykle ma datę wygaśnięcia, więc możesz mieć tylko godzinę na kliknięcie linku i aktywację konta. Nie byłoby to możliwe w przypadku plików cookie ani zmiennych sesji, ponieważ nie wiadomo, jakiego urządzenia lub przeglądarki używa klient do sprawdzania wiadomości e-mail.


11
Jednorazowy token / łącze to inna koncepcja niż uwierzytelnianie oparte na tokenach.
Emile Bergeron

Nazwa tego, co mówisz, jest również tokenem. Ale to nie jest pytanie
sajjad Yosefi
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.