Zabezpieczenia interfejsu API REST: HMAC / skrót hash vs JWT

Właśnie przeczytałem ten artykuł, który ma kilka lat, ale opisuje sprytny sposób zabezpieczenia interfejsów API REST. Głównie:

Każdy klient ma unikalną parę kluczy publiczny / prywatny
Tylko klient i serwer znają klucz prywatny; nigdy nie jest przesyłany za pośrednictwem drutu
Przy każdym żądaniu klient pobiera kilka danych wejściowych (całe samo żądanie, bieżący znacznik czasu i klucz prywatny) i przepuszcza je przez funkcję HMAC w celu wygenerowania skrótu żądania
Następnie klient wysyła normalne żądanie (zawierające klucz publiczny) i skrót do serwera
Serwer wyszukuje klucz prywatny klienta (na podstawie dostarczonego klucza publicznego) i dokonuje pewnej kontroli znacznika czasu (co, oczywiście, nie rozumiem), która sprawdza, czy żądanie nie jest ofiarą ataku powtórki
Jeśli wszystko jest w porządku, serwer używa klucza prywatnego i tej samej funkcji HMAC do wygenerowania własnego skrótu żądania
Serwer porównuje następnie oba skróty (zarówno wysłane przez klienta, jak i wygenerowane); jeśli są zgodne, żądanie jest uwierzytelniane i może być kontynuowane

Natknąłem się na JWT , który brzmi bardzo podobnie. Jednak pierwszy artykuł w ogóle nie wspomina o JWT, więc zastanawiam się, czy JWT różni się od powyższego rozwiązania uwierzytelniania, a jeśli tak, to w jaki sposób.

— smeeb
źródło

Lol ... Chciałem tylko zadać dokładnie to samo pytanie i natknąłem się na twoje. Jedną z pierwszych rzeczy, które znalazłem na temat bezpaństwowego uwierzytelnienia, był dokument AWS: docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide /... i zaimplementowałem coś takiego jak massimilianosciacco.com/… . Potem znalazłem JWS / JWT i jest jakoś podobny. Ale o ile rozumiem JWT jest standardem, a inne opisane powyżej rozwiązania to niektóre niestandardowe implementacje (niestandaryzowane). Ktoś mnie popraw, jeśli się mylę.

— nyxz

Dobrze wiedzieć, że nie tylko martwię się o takie szczegóły! JWT z pewnością czuje się podobnie, a dodatkową zaletą jest to, że jest ustandaryzowany. Zastanawiam się tylko, jak to działa (pod względem bezpieczeństwa) z tym niestandardowym rozwiązaniem HMAC.

— smeeb

Zacznijmy od bardzo podstawowej odpowiedzi.

JWT (używany w kontekście OAuth i OpenID) nie wymaga wspólnych tajnych kluczy między klientem a API. Istnieją 3 komponenty i pary 2, z których każdy dzieli klucz: klient <-> serwer identyfikacyjny, serwer identyfikacyjny <-> API.

Przenosi to najbardziej złożoność z API na serwer identyfikacyjny, API musi tylko sprawdzić, czy token został wydany przez serwer identyfikacyjny i nie został zahartowany. Aby zweryfikować, czy interfejs API sprawdza, czy podpis JWT jest poprawny ze znanym wspólnym tajnym kluczem między serwerem identyfikacyjnym a interfejsem API. Otóż to!

Sposób, w jaki serwer identyfikacyjny sprawdza tożsamość użytkownika, może się znacznie różnić (w wielu przypadkach jest to stara para nazwa użytkownika + hasło w połączeniu TLS), ale nie ma wpływu na interfejs API.

Prywatność i bezpieczeństwo wiadomości oraz samego tokena podczas korzystania z JWT są obsługiwane przez TLS, JWT nie zna takich problemów.

— Patrick
źródło