Niestandardowy nagłówek autoryzacji HTTP

124

Zastanawiałem się, czy można umieścić niestandardowe dane w nagłówku autoryzacji HTTP. Projektujemy RESTful API i możemy potrzebować sposobu na określenie niestandardowej metody autoryzacji. Na przykład nazwijmy to FIRE-TOKENuwierzytelnianiem.

Czy coś takiego byłoby ważne i dozwolone zgodnie ze specyfikacją: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

Pierwsza część drugiego ciągu (przed ':') to klucz API, druga część to skrót zapytania.

— NRaf
źródło

133

Format zdefiniowany w dokumencie RFC2617 to credentials = auth-scheme #auth-param. Tak więc, zgadzając się z fumanchu, myślę, że wyglądałby poprawiony schemat autoryzacji

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

Gdzie FIRE-TOKENjest schemat, a dwie pary klucz-wartość to parametry uwierzytelniania. Chociaż uważam, że cytaty są opcjonalne (z załącznika B do p7-auth-19) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

Uważam, że jest to zgodne z najnowszymi standardami, jest już w użyciu (patrz poniżej) i zapewnia format klucz-wartość dla prostego rozszerzenia (jeśli potrzebujesz dodatkowych parametrów).

Kilka przykładów tej składni auth-param można zobaczyć tutaj ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

— StarTrekRedneck
źródło

4

Prosty interfejs API pamięci masowej firmy Amazon oferuje inny przykład.

— biskup

18

Umieść go w osobnym, niestandardowym nagłówku.

Przeciążenie standardowych nagłówków HTTP prawdopodobnie spowoduje więcej zamieszania, niż jest to warte, i naruszy zasadę najmniejszego zaskoczenia . Może to również prowadzić do problemów ze współdziałaniem dla programistów klientów API, którzy chcą używać gotowych zestawów narzędzi, które mogą obsługiwać tylko standardową formę typowych nagłówków HTTP (takich jak Authorization).

— Brian Kelly
źródło

3

Może to być trudniejsze do osiągnięcia, niż się wydaje. Łącze, które udostępnia fumanchu (w komentarzu do jego odpowiedzi) wyjaśnia, dlaczego wprowadzenie niestandardowego nagłówka dodaje dodatkowe obciążenie związane z koniecznością ręcznego ustawiania kontroli pamięci podręcznej poprawnie.

— Jon-Eric

4

Ponadto, jeśli wysyłasz żądanie między źródłami za pośrednictwem przeglądarki, jesteś teraz na terytorium przed lotem tylko ze względu na niestandardowy nagłówek, w którym w innym przypadku mógłbyś go uniknąć. W przypadku niektórych aplikacji te żądania sumują się.

— Wil Moore III

31

Ogromne nie dla niestandardowych nagłówków uwierzytelniania. Standardowy Authorizationnagłówek z własnym schematem powinien być więcej niż wystarczający. Dodatkowo unikasz żądań pochodzenia przed lotem, jak wskazuje @wilmoore. Schematy niestandardowe nie kolidują z żadnym znanym mi w miarę współczesnym serwerem HTTP, a jeśli używasz własnego schematu, będziesz musiał sam go przeanalizować - żadna biblioteka nie powinna powodować konfliktów (w przeciwnym razie biblioteka jest źle napisana).

— Les Hazlewood,

7

Dobrym powodem przesyłania poświadczeń w Authorizationnagłówku, a nie w niestandardowym nagłówku, jest fakt, że serwery proxy i programy rejestrujące wiedzą, że traktują informacje jako poufne.

— Eron Wright,

15

Nie, to nie jest poprawna produkcja zgodnie z definicją „poświadczeń” w dokumencie RFC 2617 . Podajesz prawidłowy schemat uwierzytelniania, ale wartości parametrów auth-param muszą mieć postać token "=" ( token | quoted-string )(patrz sekcja 1.2), a Twój przykład nie używa „=” w ten sposób.

— fumanchu
źródło

1

To nie jest poprawne. Przykładowy format można znaleźć na stronie 5 dokumentu: Autoryzacja: Podstawowa QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

To prawda. Ale jak tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 mówi: „«b64token»zapis został wprowadzony do zgodności z istniejącymi systemami uwierzytelniania i może być używany tylko raz wyzwanie / poświadczenia. Nowe schematy powinny zatem używać zamiast tego składni „auth-param”, ponieważ w przeciwnym razie przyszłe rozszerzenia będą niemożliwe. " Zobacz także dyskusję na temat pamięci podręcznej dotyczącą wykonywania uwierzytelniania w niestandardowych nagłówkach.

— fumanchu

9

Stare pytanie znam, ale dla ciekawskich:

Wierz lub nie, ale ten problem został rozwiązany ~ 2 dekady temu za pomocą protokołu HTTP BASIC, który przekazuje wartość jako nazwa użytkownika: hasło zakodowane w base64. (Zobacz http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Możesz zrobić to samo, aby powyższy przykład wyglądał następująco:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— Mike Marcacci
źródło

4

Odradzałbym tę odpowiedź, ponieważ zgodnie z komentarzem do innej odpowiedzi tutaj , notacja użyta tutaj jest zgodna z istniejącymi schematami i nie jest zalecana dla nowych rozszerzeń.

— Whymarrh