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

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.

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 )

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).

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.

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/

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

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.

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?

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.

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