Wszystko, co aplikacja javascript może zrobić w kliencie przeglądarki, może zobaczyć i zrobić ktoś inny, aby uzyskać dostęp do serwera API REST zaplecza poza aplikacją.
Fakt, że aplikacja kliencka jest zaimplementowana w języku JavaScript jest nieistotny - nie można w pełni zaufać aplikacji uruchamianej na komputerze znajdującym się poza kontrolą użytkownika. Trochę trudniej jest odtworzyć kod natywny możliwy do wykrycia niż do ViewSource w aplikacji javascript, ale nie jest to niemożliwe. Nigdy nie polegaj na bezpieczeństwie przez zaciemnienie.
Najlepszym rozwiązaniem jest, aby aplikacja przeglądarki wymagała od użytkownika końcowego zalogowania się i uzyskania tokena autoryzacji od zaufanego dostawcy tożsamości oraz przedstawienia tokena autoryzacji w każdym żądaniu aplikacji przeglądarki do interfejsu API REST. Interfejs REST API może następnie zweryfikować token uwierzytelniania, aby sprawdzić, czy pochodzi on od zaufanego dostawcy oraz czy użytkownik wskazany w tokenie jest uprawniony do korzystania z interfejsu API REST.
Wiąże to autoryzację wywołań REST API z użytkownikiem zamiast z aplikacją i korzysta z sekretów (poświadczeń użytkownika), które nie znajdują się w aplikacji przeglądarki dla całego świata.
Dzięki temu można ograniczyć dostęp do interfejsu API REST w zależności od tego, który użytkownik nawiązuje połączenie. Nadal możesz także filtrować dostęp w zależności od aplikacji, która je wysyła, ale nie powinna to być główny czynnik bezpieczeństwa, ponieważ łatwiej jest skopiować opis aplikacji niż poświadczenia użytkownika.
Inną opcją może być, aby serwer WWW działał jako serwer proxy dla usługi REST API, tak aby aplikacja przeglądarki musiała przechodzić przez serwer sieci Web, aby pobierać dane z interfejsu API REST. Może to być możliwe, jeśli aplikacja przeglądarka utrzymuje stan sesji, który serwer sieciowy może zweryfikować, aby ustalić, że żądanie pochodzi z aplikacji bona-fide, a nie od kogoś innego. Chociaż może to pozwolić na wyłączenie interfejsu REST API z sieci publicznej, tak naprawdę nie zmienia to Twojego problemu z autoryzacją - właśnie przeniosłeś go na serwer internetowy, na którym możesz mieć więcej kontekstu sesji, aby odróżnić żądanie w aplikacji od żądanie międzyoperatorskie. Tenuous w najlepszym razie, niezalecane, chyba że jesteś naprawdę pewien stanu sesji aplikacji.
Bez względu na to, jakie rozwiązanie wybierzesz, faktem jest, że jeśli Twój REST API jest dostępny z aplikacji klienckiej (przeglądarki lub w inny sposób), jest to publiczny interfejs REST API i powinien być traktowany (i wzmacniany) jako taki. Nie ma czegoś takiego jak prywatny web API, do którego można uzyskać dostęp z komputera klienta.
dlaczego muszą być na 2 różnych serwerach? czy używasz różnych języków? – mpm
Nie, ten sam język jest używany na obu serwerach. Umieściłem resztę api na jednym serwerze i interfejsie na innym serwerze ze względu na skalowalność i rozłączenie problemów. – Michael