2010-10-10 25 views
13

Obecnie zastanawiam się, w jaki sposób mogę chronić mój interfejs REST API, który jest używany tylko przez moją aplikację mobilną przez inne aplikacje? Czy klucz API może być dobrym rozwiązaniem, ponieważ tylko ja znam tajny klucz API. Czy istnieje lepsze rozwiązanie?Jak chronić prywatne REST API

+0

Czy możesz wyjaśnić, czy chcesz (a) upewnić się, że tylko Ty (lub upoważnieni użytkownicy) mogą korzystać z Twojej usługi, czy (b) aby upewnić się, że tylko twoja aplikacja kliencka może korzystać z Twojej usługi? – Bruno

+0

Upewnię się, że tylko moja aplikacja kliencka może korzystać z mojej usługi. – LeonS

+0

Myślałem, że celem REST było to, że nie było potrzeby korzystania z API? (Podobnie jak RPC ...) – Anders

Odpowiedz

3

Użyj uwierzytelniania HTTP. REST polega na używaniu urządzeń dostępnych w HTTP, więc należy użyć natywnego uwierzytelniania HTTP. Przy podstawowym uwierzytelnianiu będziesz musiał korzystać z HTTPS. Jeśli nie możesz tego zrobić, użyj uwierzytelniania HTTP lub NTLM.

Wszystkie mają różne mocne i słabe strony, a nie każda z nich może być obsługiwana przez serwer HTTP i bibliotekę klienta.

+0

Więc jeśli używam podstawowego uwierzytelniania HTTP w połączeniu z HTTPS, jestem po bezpiecznej stronie? Zwłaszcza że nikt oprócz mnie nie użyje mojego API? – LeonS

+0

Leon, jeśli twój klient i serwer nie znajdują się za zaporą, musisz martwić się, że ktoś podsłuchuje twoje połączenie. Protokół HTTPS szyfruje połączenie, aby nie można go było podsłuchać, a uwierzytelnianie podstawowe zapewnia wymagany klucz interfejsu API. –

+0

Nawet jeśli udostępniam wielu użytkownikom nazwę użytkownika i hasło? Tak więc obawiam się, że ktoś inny używa mojego API z inną aplikacją. Czy mogę oprócz tego z https? – LeonS

17

Leon, ciągle mówisz "ktoś inny, używając mojego API z inną aplikacją". Chcesz powiązać swój interfejs API, aby był używany tylko przez jedną aplikację? Tak więc, nie chcesz nadawać praw dostępu użytkownikowi, ale chcesz przekazać je do instancji aplikacji uruchomionej na urządzeniu mobilnym użytkownika.

W skrócie: Nie ufasz użytkownikowi!

Cóż, w takim przypadku musisz upewnić się, że aplikacja jest zamknięta źródłowa, musisz zakodować swoje poświadczenia w swojej aplikacji w taki sposób, aby nikt nie mógł ich odzyskać lub przechowywać poświadczenia w specjalnie zaszyfrowanej formie. urządzenie, klucz odszyfrowywania, który może być odczytywany tylko przez aplikację. W pewnym sensie musisz wprowadzić formę DRM, aby uniemożliwić ludziom robienie rzeczy z danymi na ich urządzeniach mobilnych. I musisz mieć nadzieję, że nikt nie może go odtworzyć.

Jeśli twoja aplikacja staje się bardzo popularna/interesująca, możesz liczyć na to, że ludzie, którzy są bardzo, bardzo dobrzy, będą patrzyli na twoją aplikację i złamią twoje szyfrowanie zanim się zorientujesz. Może, jeśli włożysz w to tyle wysiłku, co Skype, może wtedy możesz odeprzeć ich na chwilę.

Ale zadaj sobie pytanie: Po co się męczyć? Dlaczego nie ufam moim użytkownikom? Czy naprawdę warto przeskakiwać takie obręcze, aby uniemożliwić innym aplikacjom korzystanie z mojego API?

Po prostu poprowadź użytkownika przez proces rejestracji, w którym każda instancja aplikacji otrzymuje unikalny klucz z serwera (lub unikatowe hasło uwierzytelniające HTTP) i przechowuje je gdzieś na urządzeniu mobilnym użytkownika. Następnie, aby uzyskać dostęp do interesujących funkcji w interfejsie API, wymagana jest obecność tego klucza/hasła. Ale nie przechodź zbyt długo, aby ukryć lub zaszyfrować klucz, gdy przechowujesz go lokalnie, nie jest to tego warte. Jeśli później wykryjesz nadużycia, zawsze możesz cofnąć prawa dostępu do konkretnego konta na serwerze.