• O WordPressie
    • WordPress.org
    • Dokumentacja
    • Naucz się WordPressa
    • Pomoc
    • Uwagi
  • Zaloguj się
Marek Zając Marek Zając
  • contact@zajacmarek.com Zapraszam do kontaktu
  • Strona główna
  • O mnie
  • Kursy
  • Konsultacje
  • Kanał Youtube
  • 7 maja 2017
  • Marek Zając
  • 2 Comments

Json Web Token

Nadszedł ten moment w projekcie Let’s Write! kiedy dodawanie po stronie widoku mocków dla operacji bazodanowych stało się bardziej czasochłonne niż dodawanie nowych funkcjonalności. Z tego powodu zmieniłem nieco plany i już teraz zaczynam zajmować się warstwą serwerową. Pierwsze co postanowiłem obsłużyć to logowanie i rejestrowanie użytkownika. Żeby móc zapewnić bezpieczną i szybko autoryzację będę korzystał z Json Web Token. Implementacja pojawi się niedługo. W tym wpisie powiem tylko pokrótce co to jest.

Json Web Token (JWT) to rodzaj tokenu przechowywanego po stronie klienta. Jest on oparty na formacie JSON, jak z resztą wskazuje jego nazwa. Token jest zaszyfrowany po stronie serwera i tylko serwer ma klucz pozwalający zweryfikować autentyczność tokenu.

JWT składa się z trzech części. Wszystkie dane w tokenie są przepuszczone przez algorytm Base64 i dopiero w takiej postaci przechowywane.

Header

Informacja o algorytmie szyfrujących wykorzystanym przy generowaniu tokenu.

Payload

Dane, które chcemy przechowywać po stronie klienta. Nie są one zaszyfrowane. Zwykle przechowuje się tutaj dane o użytkowniku takie jak Id czy jego uprawnienia. Dzięki temu można w łatwy sposób mieć dostęp do najczęściej używanych danych po stronie klienta.

Signature

Podpis cyfrowy. Połączone w jedną całość i zaszyfrowane przez serwer header i payload. Dopiero kiedy serwer, otrzymując token razem z zapytaniem, odszyfruje tą część i porówna dane z payload przepuszcza zapytanie jako prawidłowe.

 

Zastosowanie Json Web Token pozwala przy okazji ograniczyć ilość zapytań do bazy. Wystarczy, że przy logowaniu pobierzemy i wyślemy do widoku takie dane jak id użytkownika, jego role, imię, nazwisko, może link do avatara i już nie musimy ich pobierać za każdym razem kiedy będziemy chcieli ich użyć, czy to po stronie widoków czy nawet po stronie serwera później. W końcu skoro podpis się zgadza to znaczy, że dane są prawidłowe i można im zaufać.

 

 

Related Posts
  • Asynchroniczność w ASP.NET Core 16 stycznia 2020
  • Nie lubię TEGO projektu! 15 stycznia 2020
  • Pierwsze portfolio na GitHubie – Przewodnik 14 stycznia 2020
2 komentarze
  1. Reply
    Piotr 31 sierpnia 2018

    „Ograniczenie zapytań…” to chyba trochę słaby argument bo równie dobrze można trzymać dane bez zapytań do bazy po stronie serwera. Np. w zmiennych sesji. Poza tym jeśli taki token będzie np. w cookie to między serwerem a klientem te cookie będzie w kółko wędrować. No i dochodzi limit wielkości ciastka….

    • Reply
      Marek Zając 31 sierpnia 2018

      W takim tokenie nie trzymamy zazwyczaj tyle informacji, żeby osiągnąć limit 4kB na ciastko.
      Sesja po stronie serwera staje się uciążliwa i przesadnie skomplikowana już w przypadku zastosowania load balancera kiedy każdy z serwerów musi do takiej sesji mieć dostęp. Nie mówiąc już o przypadku kiedy serwer do autoryzacji jest osobną usługą albo mamy wręcz architekturę mikroserwisów.
      https://stackoverflow.com/questions/43452896/authentication-jwt-usage-vs-session/45214431#45214431

Leave a Comment Cancel Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Copyright 2020 Bizix, All rights reserved.
  • POLITYKA PRYWATNOŚCI I PLIKÓW COOKIES