Gdzie umieścić klucz API: niestandardowy nagłówek HTTP VS nagłówek autoryzacji z niestandardowym schematem

19

Projektuję interfejs API REST przy użyciu autoryzacji / uwierzytelnienia za pomocą klucza API.

Próbowałem dowiedzieć się, jakie jest dla niego najlepsze miejsce i odkryłem, że wiele osób sugeruje użycie niestandardowego nagłówka HTTP, takiego jak ProjectName-Api-Keynp .:

ProjectName-Api-Key: abcde

ale także możliwe i ideologicznie poprawne jest użycie Authorizationnagłówka z niestandardowym schematem, np .:

Authorization: ApiKey abcde

Z drugiej strony odkryłem, że niestandardowy schemat autoryzacji może być nieoczekiwany i nieobsługiwany przez niektórych klientów i prowadzi do niestandardowego kodu, więc lepiej jest użyć niestandardowego nagłówka, ponieważ klienci nie mają żadnych oczekiwań w stosunku do niego.

W jaki sposób wolisz wysłać klucz API?

RomanG
źródło
Projekty pod moimi wytycznymi używają Authorization: Bearer <token>nagłówka i nigdy nie było z tym żadnego problemu. Tokenami są JWT .
Andy,
1
@DavidPacker Jak rozumiem, Bearerschemat jest używany wyłącznie z oAuth2. Zastosowanie go osobno od oAuth brzmi jak niewłaściwe użycie. Dlaczego warto używać tego schematu, jeśli nie ma prawdy? Nawiasem mówiąc, miałem problemy z wyborem rodzaju autoryzacji dla mojego interfejsu API. Interfejs API będzie dostępny tylko dla jednej zaufanej usługi, więc zbadałem przepływ poświadczeń klienta oAuth2 i w moim przypadku nie znalazłem żadnych korzyści w porównaniu z ApiKey.
RomanG
@DavidPacker Wtedy zrozumiałem, że autoryzację ApiKey można uznać za prawidłową implementację oAuth, jeśli ApiKeyzostanie zmieniona jej nazwa i zinterpretowana jako Access Tokenudzielona klientowi bez upływu terminu ważności. Jest to rodzaj aspektu filozoficznego, postanowiłem nie wprowadzać skomplikowanych definicji, jeśli mój przypadek można opisać w prosty sposób, i postanowiłem po prostu nazwać go „ApiKey”. Jeśli Twój protokół implementuje standard oAuth, mogę zgodzić się na jego użycie Bearer, ale tak nie jest, chyba nie można zastosować tego schematu.
RomanG
2
Za bardzo się ograniczasz. Konsument API nie może mniej dbać o to, czy wdrożyłeś OAuth, czy nie. To, na czym im zależy, to bezpieczeństwo tokenów, to, że wydawanie tokenów działa i że można je odpowiednio uwierzytelnić. Zalecają użycie nośnika bezpośrednio w dokumentacji JWT . JWT doskonale pasuje do schematu elementu nośnego i nie mogłem więcej polecić JWT. Idealnie nadają się do aplikacji REST, ponieważ można uwierzytelnić użytkownika nawet bez wchodzenia do bazy danych - chyba że potrzebujesz funkcji odwołania tokena.
Andy,
1
(jedź obok) ... pamiętaj, aby wiedzieć, że klucze API są wspólnymi tajemnicami zwykle dzielonymi między skonfigurowaną stroną ufającą a wystawcą uwierzytelnienia, aby nie przekazywać tożsamości ani autoryzacji. Innymi słowy, mają one jedynie na celu zainicjowanie uzgadniania zabezpieczeń, a nie wynik uwierzytelnienia. Klucz API komunikuje Twoje uprawnienia do zidentyfikowania się na tle zaufanego wystawcy uwierzytelnienia systemu. Używanie klucza jako tokena do kontrolowania bezpiecznego dostępu do zasobów jest złe juju
K. Alan Bates

Odpowiedzi:

14

Jeśli korzystasz z autoryzacji, zachowaj spójność

Niektórzy będą argumentować, że nie jest konieczne ( i nie tak dawno temu zgodziłbym się z nimi ), ale w dzisiejszych czasach, jeśli użyjemy Authorizationnagłówka, powinniśmy poinformować o typie tokena, ponieważ klucze API same w sobie nie opisują 1 .

Dlaczego uważam, że jest to konieczne i dlaczego uważam, że to ważne? Ponieważ obecnie obsługa różnych protokołów uwierzytelniania / autoryzacji stała się koniecznością. Jeśli planujemy używać Authorizationnagłówka dla wszystkich tych protokołów, musimy zapewnić spójność naszej usługi uwierzytelniania. Sposób komunikowania się, jaki rodzaj tokena wysyłamy i jaki protokół autoryzacji należy zastosować, powinien również znaleźć się w nagłówku.

Authorization: Basic xxxx
Authorization: Digest xxxx
Authorization: Bearer xxxx
Authorization: ApiKey-v1 xxxx
Authorization: ApiKey-v2 xxxx

Nie przejmowałem się tym, ale po pracy z aplikacjami klienckimi, których aktualizacje nie były gwarantowane (głównie telefony komórkowe i czujniki), zacząłem. Zacząłem być bardziej ostrożny w sposobie wdrażania zabezpieczeń, aby móc je rozszerzać bez bałaganu z klientami i bez nadmiernego bólu po stronie serwera.

Obawy

Problemy, z jakimi miałem do czynienia przy wdrażaniu własnych programów, były podobne do tych, które skomentowałem.

Z drugiej strony uznałem, że niestandardowy schemat autoryzacji może być nieoczekiwany i nieobsługiwany przez niektórych klientów, co i tak prowadzi do kodu niestandardowego

Powiedz klientom , powiedzmy biblioteki, frameworki, odwrotne proxy .

Zalety

Jedną ważną zaletą jest pamięć podręczna. Udostępnione pamięci podręczne nie buforują nagłówka (i to oczywiście dobrze), chyba że powiesz inaczej.

Więc autoryzacja czy niestandardowy nagłówek?

Z mojego doświadczenia Authorizationwynika, że wdrożenie własnego schematu zajęło mi tyle samo pracy (lub więcej) niż wdrożenie niestandardowych nagłówków autoryzacji, z niewielką różnicą w zakresie większej swobody projektowania i większej kontroli nad pamięcią podręczną, gdy korzystam z niestandardowych nagłówków. Powód jest raczej głupi, przez większość czasu mam Cache-controlustawiony na no-cachelub no-store, co pozwala mi uczynić połączenia z serwerem bardziej deterministycznymi (jest to ważne, jeśli chodzi o śledzenie i testowanie) bez względu na topologię sieci.


1: Uważam, że ta odpowiedź jest bardzo jasna w odniesieniu do kluczy API

Laiv
źródło
4
Korzystanie z X-jest przestarzałe od 2012: stackoverflow.com/a/3561399/923720
Darkhogg
1
ops! Nie wiedziałem Edytowane i naprawione.
Laiv
Przed tym pytaniem pomyślałem, że większość umieści klucz API w adresie URL, ale użyłem HTTPS, aby go ukryć. Dobrze jest zobaczyć kilka alternatyw. Na przykład Contentful pozwala na autoryzację lub zapytanie pamameter: contentful.com/developers/docs/references/content-delivery-api/…
user949300
1
@ user949300 ... korzystanie z zaszyfrowanego wspólnego klucza (np. klucz API w URI przez SSL) jest oczywiście bezpieczniejsze niż nic, ale łatwo je sfałszować, jeśli zostanie przechwycone i nie zapewni granulacji tożsamości. Nigdy nie korzystałem z api_keys do celów innych niż komunikacja maszyna-maszyna, w której dopasowuję wspólny sekret między zaufanymi stronami i tożsamościami komputerów na białej liście, upoważnionych do działania z tym wspólnym sekretem. Po wykonaniu połączenia maszyna-maszyna, operator wykonuje uwierzytelnienie za pomocą innych środków.
K. Alan Bates
@K. Alan Bates Większość moich interakcji z API dotyczyło względnie „nieistotnych” rzeczy, takich jak darmowe poziomy geokodowania, prognozy pogody i tym podobne, w których klucz API służy raczej ograniczaniu szybkości niż poważnym tajemnicom użytkowników. Tak więc, jak w przypadku OP, zależy od wymaganego poziomu bezpieczeństwa.
user949300,