Jakie są główne różnice między uwierzytelnianiem JWT i OAuth?


356

Mam nowe SPA z bezstanowym modelem uwierzytelniania przy użyciu JWT. Często jestem proszony o odesłanie OAuth w przypadku przepływów uwierzytelniania, takich jak proszenie mnie o wysyłanie „tokenów nośnika” dla każdego żądania zamiast prostego nagłówka tokena, ale myślę, że OAuth jest o wiele bardziej złożony niż zwykłe uwierzytelnianie oparte na JWT. Jakie są główne różnice, czy należy sprawić, aby uwierzytelnianie JWT zachowywało się jak OAuth?

Używam również JWT jako mojego XSRF-TOKEN, aby zapobiec XSRF, ale jestem proszony o oddzielenie ich? Czy powinienem je rozdzielić? Każda pomoc tutaj zostanie doceniona i może prowadzić do opracowania zestawu wytycznych dla społeczności.

Odpowiedzi:


330

TL; DR Jeśli masz bardzo proste scenariusze, takie jak pojedyncza aplikacja kliencka, pojedynczy interfejs API, może nie być opłacalne przejście na OAuth 2.0, z drugiej strony wiele różnych klientów (opartych na przeglądarce, natywnych urządzeniach mobilnych, po stronie serwera itd.), a następnie przestrzeganie reguł OAuth 2.0 może sprawić, że będzie łatwiejsze w zarządzaniu niż próba uruchomienia własnego systemu.


Jak stwierdzono w innej odpowiedzi, JWT ( Learn JSON Web Tokens ) jest tylko formatem tokenów, definiuje kompaktowy i niezależny mechanizm przesyłania danych między stronami w sposób, który można zweryfikować i zaufać, ponieważ jest podpisany cyfrowo. Dodatkowo reguły kodowania JWT sprawiają, że tokeny te są bardzo łatwe w użyciu w kontekście HTTP.

Będąc samodzielnymi (rzeczywisty token zawiera informacje na dany temat), są one również dobrym wyborem do implementacji bezstanowych mechanizmów uwierzytelniania (aka Look mama, brak sesji! ). Idąc tą drogą i jedyną rzeczą, którą musi przedstawić strona, aby uzyskać dostęp do chronionego zasobu, jest sam token, dany token można nazwać tokenem nośnym.

W praktyce to, co robisz, można już zaklasyfikować jako oparte na tokenach nośnika. Należy jednak wziąć pod uwagę, że nie używasz tokenów nośnych zgodnie ze specyfikacjami związanymi z OAuth 2.0 (patrz RFC 6750 ). Oznaczałoby to, opierając się na Authorizationnagłówku HTTP i używając Bearerschematu uwierzytelniania.

Jeśli chodzi o wykorzystanie JWT do zapobiegania CSRF bez znajomości dokładnych szczegółów, trudno jest ustalić ważność tej praktyki, ale szczerze mówiąc, nie wydaje się to poprawne i / lub opłacalne. Poniższy artykuł ( Pliki cookie a tokeny: ostateczny przewodnik ) może być przydatnym materiałem do przeczytania na ten temat, szczególnie w sekcji Ochrona XSS i XSRF .

Ostatnia rada, nawet jeśli nie musisz korzystać z pełnej wersji OAuth 2.0, zdecydowanie zaleciłbym przekazanie tokena dostępu w Authorizationnagłówku zamiast korzystania z niestandardowych nagłówków . Jeśli tak naprawdę są tokenami okaziciela, postępuj zgodnie z zasadami RFC 6750, jeśli nie, zawsze możesz utworzyć niestandardowy schemat uwierzytelniania i nadal używać tego nagłówka.

Nagłówki autoryzacji są rozpoznawane i specjalnie traktowane przez serwery proxy i serwery HTTP. Dlatego użycie takich nagłówków do wysyłania tokenów dostępu do serwerów zasobów zmniejsza prawdopodobieństwo wycieku lub niezamierzonego przechowywania uwierzytelnionych żądań w ogóle, a zwłaszcza nagłówków autoryzacji.

(źródło: RFC 6819, sekcja 5.4.1 )


2
Czy to oznacza, że ​​jeśli używam uwierzytelniania JWT w aplikacji mobilnej, nie muszę dołączać CSRF do jego żądania POST? W przeciwieństwie do interfejsu internetowego z formularzami?
user805981,

2
Pliki cookie kontra tokeny: Przewodnik definitywny, tj. Auth0.com/blog/cookies-vs-tokens-definitive-guide nie działa. To kolejny świetny post na dyskusji: stackoverflow.com/questions/37582444/…
Siddharth Jain

1
„są również dobrym wyborem do implementacji bezstanowych mechanizmów uwierzytelniania (aka Look mama, brak sesji!)”. Jeśli potrzebujesz sposobu na unieważnienie tokena, ponieważ powiedzmy, że był wyciekły lub przechwycone, lub użytkownik po prostu się wylogował i usunął token nie jest wystarczająco bezpieczny, ponieważ token jest nadal ważny, dlatego musisz przechowywać je w jakiejś bazie danych, więc myślę, że musi istnieć pewne pojęcie sesji na serwerze dla celów bezpieczeństwa lub zwykłej czarnej listy tokenów. Można powiedzieć, że w tym celu użyj tokenów „odświeżania”. Ale tokenów odświeżania można również przechwycić, a konsekwencje są znacznie gorsze.
Konrad

1
@Konrad, wdrożyłem podobny mechanizm, który przechowywał nieużywane ważne tokeny w tabeli, zwalniając je stamtąd po wygaśnięciu. Dla każdego przychodzącego żądania napisałem kod, aby sprawdzić przychodzący token pod kątem „nieużywanych prawidłowych tokenów”. Mimo że działa, zawsze miałem wątpliwości - powinien istnieć lepszy sposób radzenia sobie z nieużywanymi, ale wciąż ważnymi tokenami.
Tech Junkie

2
Z drugiej strony tokeny odświeżające po prostu komplikują implementację klienta. Ponieważ jeśli twój token dostępu wygaśnie, musisz sobie z tym poradzić, użytkownik będzie wkurzony, jeśli wylogujesz go bez żadnej możliwości nawet ręcznego odświeżenia sesji (tak jak robią to banki). Jest to nieco więcej do zrobienia, również stosowanie standardowych metod uwierzytelniania (OID) i autoryzacji (OAuth) może często stanowić przesadę.
Konrad

281

OAuth 2.0 definiuje protokół, tzn. Określa sposób przesyłania tokenów, JWT definiuje format tokenów.

OAuth 2.0 i „Uwierzytelnianie JWT” mają podobny wygląd, jeśli chodzi o (drugi) etap, w którym klient przedstawia token serwerowi zasobów: token jest przekazywany w nagłówku.

Ale „Uwierzytelnianie JWT” nie jest standardem i nie określa, w jaki sposób Klient uzyskuje token w pierwszej kolejności (pierwszy etap). Stąd bierze się postrzegana złożoność protokołu OAuth: definiuje on także różne sposoby, w jaki klient może uzyskać token dostępu z czegoś, co nazywa się serwerem autoryzacji.

Prawdziwa różnica polega na tym, że JWT jest tylko formatem tokena, OAuth 2.0 to protokół (który może wykorzystywać JWT jako format tokena).


10
Czy w większości przypadków implementacje protokołu oAuth używają JWT jako formatu tokena? Jeśli nie, co jest najczęściej?
James Wierzba,

14
Format tokenów w oauth jest niezdefiniowany, ale JWT powinien działać dobrze
vikingsteve

129

Po pierwsze musimy rozróżnić JWT i OAuth. Zasadniczo JWT jest formatem tokena. OAuth to protokół autoryzacji, który może wykorzystywać JWT jako token. OAuth używa pamięci po stronie serwera i klienta. Jeśli chcesz dokonać prawdziwego wylogowania, musisz przejść do OAuth2. Uwierzytelnianie za pomocą tokena JWT nie może się faktycznie wylogować. Ponieważ nie masz serwera uwierzytelniania, który śledzi tokeny. Jeśli chcesz udostępnić interfejs API klientom zewnętrznym, musisz także używać OAuth2. OAuth2 jest bardzo elastyczny. Implementacja JWT jest bardzo łatwa i nie zajmuje dużo czasu. Jeśli Twoja aplikacja potrzebuje takiej elastyczności, powinieneś skorzystać z OAuth2. Ale jeśli ten scenariusz nie jest potrzebny, wdrożenie OAuth2 jest stratą czasu.

Token XSRF jest zawsze wysyłany do klienta w każdym nagłówku odpowiedzi. Nie ma znaczenia, czy token CSRF jest wysyłany w tokenie JWT, czy nie, ponieważ token CSRF jest zabezpieczony sam z siebie. Dlatego wysyłanie tokenu CSRF w JWT nie jest konieczne.


7
Nie rozumiem, dlaczego ta odpowiedź ma wiele pozytywnych opinii, stwierdza, że ​​„OAuth jest strukturą uwierzytelniania” i jest to całkowicie błędne. OAuth to protokół autoryzacji i tylko protokół autoryzacji.
Michael

4
Cześć @Michael, jest w tym zbyt wiele nieporozumień. Zredagowałem swój komentarz, dziękuję.
Melikşah Şimşek

6
@Michael, proszę docenić odpowiedź innego Bcz, który podzielił się z nami swoją wyrafinowaną wiedzą i naprawdę podobała mi się odpowiedź.
Yasir Shabbir Choudhary,

Czy mówicie, że Oauth to tylko kawałek Standardów, których powinni przestrzegać programiści? Czy to naprawdę ramy?
StormTrooper

65

JWT (JSON Web Tokens) - To tylko format tokena. Tokeny JWT są zakodowanymi strukturami danych JSON zawierającymi informacje o wystawcy, temacie (roszczeniach), terminie ważności itp. Jest on podpisany pod kątem zabezpieczenia przed manipulacją i autentyczności oraz może być szyfrowany w celu ochrony informacji o tokenie przy użyciu podejścia symetrycznego lub asymetrycznego. JWT jest prostszy niż SAML 1.1 / 2.0 i obsługiwany przez wszystkie urządzenia i jest bardziej wydajny niż SWT (Simple Web Token).

OAuth2 - OAuth2 rozwiązuje problem polegający na tym, że użytkownik chce uzyskać dostęp do danych za pomocą oprogramowania klienckiego, takiego jak aplikacje internetowe oparte na przeglądarce, natywne aplikacje mobilne lub aplikacje komputerowe. OAuth2 służy wyłącznie do autoryzacji, oprogramowanie klienckie może być autoryzowane do uzyskiwania dostępu do zasobów w imieniu użytkownika końcowego za pomocą tokena dostępu.

OpenID Connect - OpenID Connect opiera się na OAuth2 i dodaje uwierzytelnianie. OpenID Connect dodaje pewne ograniczenia do OAuth2, takie jak UserInfo Endpoint, ID Token, wykrywanie i dynamiczna rejestracja dostawców OpenID Connect i zarządzanie sesjami. JWT jest obowiązkowym formatem tokena.

Ochrona CSRF - Nie musisz wdrażać ochrony CSRF, jeśli nie przechowujesz tokena w pliku cookie przeglądarki.

Możesz przeczytać więcej szczegółów tutaj http://proficientblog.com/microservices-security/


3
Brak plików cookie == Brak ochrony CSRF. Jeśli nie używasz plików cookie do autoryzacji, nie musisz się martwić o ochronę CSRF.
niranjan harpale

51

Wygląda na to, że wszyscy, którzy tu odpowiedzieli, nie zauważyli punktu spornego OAUTH

Z Wikipedii

OAuth to otwarty standard delegowania dostępu, powszechnie stosowany jako sposób na udzielenie internautom dostępu do stron internetowych lub aplikacji do ich informacji na innych stronach internetowych, ale bez podawania im haseł [1]. Ten mechanizm jest używany przez firmy takie jak Google, Facebook, Microsoft i Twitter, aby umożliwić użytkownikom udostępnianie informacji o swoich kontach aplikacjom lub stronom trzecim.

Kluczową kwestią jest tutaj access delegation. Dlaczego ktokolwiek miałby tworzyć OAUTH, gdy istnieje uwierzytelnianie oparte na identyfikatorze / pwd, wspierane przez uwierzytelnianie wieloczynnikowe, takie jak OTP, a ponadto może być zabezpieczone przez JWT, które są używane do zabezpieczenia dostępu do ścieżek (jak zakresy w OAUTH) i ustawienia wygaśnięcia dostęp

Nie ma sensu korzystać z OAUTH, jeśli konsumenci uzyskują dostęp do swoich zasobów (punktów końcowych) tylko za pośrednictwem zaufanych stron internetowych (lub aplikacji), które są ponownie hostowane w punktach końcowych

Możesz przejść uwierzytelnianie OAUTH tylko wtedy, gdy jesteś OAUTH providerw przypadkach, gdy właściciele zasobów (użytkownicy) chcą uzyskać dostęp do swoich (twoich) zasobów (punktów końcowych) za pośrednictwem klienta zewnętrznego (aplikacja zewnętrzna). I jest dokładnie stworzony do tego samego celu, chociaż możesz go nadużywać w ogóle

Kolejna ważna uwaga:
swobodnie używasz słowa authenticationJWT i OAUTH, ale żadne nie zapewnia mechanizmu uwierzytelniania. Tak, jeden to mechanizm tokena, a drugi to protokół, ale po uwierzytelnieniu są one używane tylko do autoryzacji (zarządzania dostępem). Musisz poprzeć OAUTH za pomocą uwierzytelnienia typu OPENID lub własnych poświadczeń klienta


4
OAuth może być również używany dla własnych klientów, niekoniecznie tylko dla stron trzecich. Dokładnie to robi typ Grantu poświadczeń hasła.
harpratap 12.01.2018

1
Szukałem w Google takiej konkretnej odpowiedzi, ale nie mogłem jej znaleźć. Wszyscy mówili tylko o definicjach, np. Token vs protokół. Twoja odpowiedź wyjaśniła prawdziwy cel używania jednego nad drugim. Dziękuję bardzo!
Vivek Goel

9

znajdź główne różnice między JWT i OAuth

  1. OAuth 2.0 definiuje protokół, a JWT definiuje format tokena.

  2. OAuth może używać JWT jako formatu tokenu lub tokena dostępu, który jest tokenem nośnym.

  3. OpenID Connect najczęściej używa JWT jako formatu tokena.


6

JWT to otwarty standard, który określa kompaktowy i niezależny sposób bezpiecznego przesyłania informacji między stronami. Jest to protokół uwierzytelniania, w którym zezwalamy na przesyłanie zakodowanych roszczeń (tokenów) między dwiema stronami (klientem i serwerem), a token jest wydawany po zidentyfikowaniu klienta. Przy każdym kolejnym żądaniu wysyłamy token.

Podczas gdy OAuth2 jest ramą autoryzacji, gdzie ma ogólne procedury i konfiguracje zdefiniowane w tych ramach. JWT może być używany jako mechanizm wewnątrz OAuth2.

Możesz przeczytać więcej na ten temat tutaj

OAuth czy JWT? Którego użyć i dlaczego?


5

Pytanie jest częste, ale nie jest całkiem rozsądne. JWT jest rodzajem tokena, a OAuth jest strukturą opisującą sposób wydawania tokenów.

Co rozumiemy przez „framework”? Tylko sekwencja żądań i odpowiedzi oraz formaty tych, które mogą i powinny być używane do żądania tokenów. OAuthv2 opisuje osobne „przepływy” lub typy przydziałów dla różnych scenariuszy i ma różne rozszerzenia (takie jak PKCE) do zwiększania bezpieczeństwa poszczególnych przepływów.

Rezultatem zapytania o token za pośrednictwem dotacji OAuthV2 jest ... token. Ta rzecz jest następnie używana jako „token na okaziciela”, co oznacza, że ​​każda strona, która posiada token, może go przedstawić podczas składania wniosku o usługę interfejsu API (np. „Jaka jest równowaga na mojej karcie wartości zgromadzonej?”). Jako token na okaziciela działa jak gotówka. Jeśli go trzymasz, możesz go użyć. (Chociaż w odróżnieniu od pieniędzy gotówkowych, token nie używa go i gubi. Być może lepszą analogią jest bilet całodzienny w systemie transportu publicznego lub bilet całodniowy w Disneyworld.)

JWT jest szczególnym typem tokena, a JWT można absolutnie wykorzystać jako token Nośnika OAuth. W rzeczywistości jest to najczęstsza praktyka. W świetle tego „JWT vs OAuth” to porównanie jabłek i wózków jabłkowych.

Często ludzie myślą, że „token OAuth” zawsze implikuje nieprzezroczysty token - losową sekwencję znaków alfanumerycznych, która nie zawiera nieodłącznego znaczenia - przyznawaną przez aptekę tokenów OAuth, którą można następnie zweryfikować tylko przez ten sam system aptek OAuth. Ale to nie jedyny rodzaj tokenu OAuth. Nieprzezroczysty token jest jednym z rodzajów tokenów; JWT może być używany jako inny rodzaj tokena OAuth.

Natomiast JWT nie są nieprzejrzyste. JWT nie jest „wskaźnikiem” ani odniesieniem do informacji. W rzeczywistości zawiera wiele konkretnych informacji, które mogą zostać wyodrębnione i zinterpretowane przez każdą stronę, która ma token. Ponieważ JWT zawiera prawdziwe informacje, JWT może być duży; 300 bajtów, 500 bajtów lub więcej, w zależności od zawartych w nim oświadczeń i algorytmu użytego do podpisania go. Kiedy ludzie mówią, że „JWT są samo-walidujące”, to znaczy, że każdy posiadacz JWT może go otworzyć, zweryfikować, a następnie podjąć decyzję o autoryzacji na podstawie przedstawionych w nim oświadczeń. Sprawdzanie poprawności JWT oznacza: weryfikację jego struktury, dekodowanie kodowania base64, weryfikację poprawności klucza, weryfikację podpisu, a następnie weryfikację wymaganych oświadczeń na tokenie, sprawdzenie wygaśnięcia. To nie jest prosta sprawa, raczej proces wieloetapowy, ale oczywiście istnieje wiele bibliotek w różnych językach programowania, które pomagają w tym, i oczywiście istnieje zasada VerifyJWT, która pomaga to zrobić w ramach proxy Apigee Edge API. Chodzi o to, że każdy posiadacz lub odbiorca może zweryfikować token. Z tego powodu mówimy, że JWT obsługuje „Federację” - każdy może wygenerować token, a każdy może odczytać i zweryfikować token.

niestandardowe roszczenia. Zarówno JWT, jak i nieprzezroczyste tokeny OAuth mogą zawierać niestandardowe roszczenia dotyczące tego tematu. bezpieczeństwo. Oba są tokenami na okaziciela. Oba muszą być chronione jako tajemnice. wygaśnięcie. Oba mogą być oznaczone datą ważności. Oba można odświeżyć. Mechanizm uwierzytelnienia lub doświadczenie. Oba mogą prezentować to samo doświadczenie użytkownika.


0

Jwt to ścisły zestaw instrukcji dotyczących wydawania i sprawdzania podpisanych tokenów dostępu. Tokeny zawierają oświadczenia, które są używane przez aplikację w celu ograniczenia dostępu do użytkownika

Z drugiej strony OAuth2 nie jest protokołem, jest to delegowane środowisko autoryzacji. pomyśl bardzo szczegółową wytyczną, pozwalającą użytkownikom i aplikacjom autoryzować określone uprawnienia do innych aplikacji zarówno w ustawieniach prywatnych, jak i publicznych. OpenID Connect, który jest oparty na OAUTH2, zapewnia uwierzytelnianie i autoryzację. Zawiera szczegółowe informacje na temat tego, jak wiele różnych ról, użytkowników w systemie, aplikacji po stronie serwera, takich jak interfejs API, oraz klientów, takich jak strony internetowe lub natywne aplikacje mobilne, można uwierzytelniać przy każdym innym

Uwaga oauth2 może współpracować z jwt, elastyczną implementacją, rozszerzalną na różne aplikacje


Wygląda na to, że masz to dokładnie odwrotnie.
jbruni
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.