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

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?

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ą ¹ .

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}