Utworzyłem uwierzytelnianie oparte na JWT w mojej aplikacji interfejsu API sieci Web. Nie jestem w stanie określić różnicy między
- Podstawowy token
- Token okaziciela
Czy ktoś może mi pomóc?
Uwierzytelnianie w interfejsie Web API Basic vs Bearer
Odpowiedzi:
Schematy uwierzytelniania Basic i Digest są przeznaczone do uwierzytelniania przy użyciu nazwy użytkownika i klucza tajnego (patrz RFC7616 i RFC7617 ).
Schemat uwierzytelniania okaziciela jest przeznaczony do uwierzytelniania przy użyciu tokenu i jest opisany w dokumencie RFC6750 . Nawet jeśli ten schemat pochodzi ze specyfikacji OAuth2, nadal możesz go używać w dowolnym innym kontekście, w którym tokeny są wymieniane między klientem a serwerem.
Jeśli chodzi o uwierzytelnianie JWT i ponieważ jest to token, najlepszym wyborem jest schemat uwierzytelniania okaziciela. Niemniej jednak nic nie stoi na przeszkodzie, aby skorzystać z niestandardowego schematu, który może pasować do Twoich wymagań.
Uwierzytelnianie podstawowe przesyła poświadczenia jako pary identyfikator użytkownika / hasło, zakodowane przy użyciu base64. Klient wysyła żądania HTTP zAuthorizationnagłówkiem zawierającym słowoBasicsłowo, po którym następuje spacja ibase64-encodedciąg nazwa użytkownika: hasło.
Autoryzacja: Podstawowa ZGVtbzpwQDU1dzByZA ==
Uwaga: W przypadku uwierzytelniania podstawowego, ponieważ identyfikator użytkownika i hasło są przesyłane przez sieć w postaci zwykłego tekstu (kodowane są w standardzie base64, ale base64 to kodowanie odwracalne), podstawowy schemat uwierzytelniania nie jest bezpieczny. HTTPS / TLS powinien być używany w połączeniu z uwierzytelnianiem podstawowym.
Uwierzytelnianie okaziciela (zwane także uwierzytelnianiem tokenów ) obejmuje tokeny zabezpieczające zwane tokenami okaziciela. Nazwę „Uwierzytelnianie okaziciela” można rozumieć jako „ udzielenie dostępu okazicielowi tego tokena ”. Token okaziciela to tajemniczy ciąg znaków, zwykle generowany przez serwer w odpowiedzi na żądanie logowania. Klient musi wysłać ten token w nagłówku Authorization podczas wysyłania żądań do chronionych zasobów:
Autoryzacja: Bearer <token>
Uwaga: Podobnie jak w przypadku uwierzytelniania podstawowego, uwierzytelnianie nośnika powinno być używane tylko przez HTTPS (SSL) .
więc oba są autoryzacją, a nie autoryzacją. W pierwszym wysyłasz ciąg zakodowany w base64 i uzyskujesz autoryzację, podczas gdy w drugim odzyskujesz token i używasz go do dostępu do zasobów
—
burza mózgów
jaka jest zaleta przekazywania tokena nad nazwą użytkownika / hasłem?
—
Muhammad Umer
@MuhammadUmer możesz unieważnić tokeny, a także przyznać im szczegółowy dostęp (tj. Tylko dostęp do odczytu).
—
Mihai
Znalazłem odpowiedź i było tak, że nie musisz czytać db z tokenem, możesz użyć krypto do walidacji tokena, najlepiej dla mikrousług, które nie mają stanu sesji współdzielonej, chociaż istnieje system równoważenia obciążenia, który może naprawić jednego użytkownika jedna usługa, ale nadal działa.
—
Muhammad Umer