Dostosuj nagłówek HTTP autoryzacji

Question 1

Muszę uwierzytelnić klienta, kiedy wysyła żądanie do API. Klient ma API-token i myślałem o użyciu standardowego Authorizationnagłówka do wysłania tokena na serwer.

Normalnie ten nagłówek jest używany do Basici Digestuwierzytelniania. Ale nie wiem, czy mogę dostosować wartość tego nagłówka i użyć niestandardowego schematu uwierzytelniania, np .:

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

Poleciłbyś to czy nie? Czy jest lepsze podejście do wysyłania tokena?

Question 2

Możesz tworzyć własne niestandardowe schematy uwierzytelniania, które używają Authorization:nagłówka - na przykład tak działa OAuth .

Z reguły jeśli serwery lub serwery proxy nie rozumieją wartości standardowych nagłówków, zostawiają je w spokoju i ignorują. To tworzenie własnych kluczy nagłówków , które często mogą dawać nieoczekiwane rezultaty - wiele serwerów proxy usuwa nagłówki z nazwami, których nie rozpoznają.

To powiedziawszy, prawdopodobnie lepszym pomysłem jest użycie plików cookie do przesyłania tokena, a nie Authorization:nagłówka, z tego prostego powodu, że pliki cookie zostały wyraźnie zaprojektowane do przenoszenia wartości niestandardowych, podczas gdy specyfikacja wbudowanych metod uwierzytelniania HTTP tak naprawdę nie mówi tak czy inaczej - jeśli chcesz zobaczyć, co dokładnie mówi, zajrzyj tutaj .

Inną kwestią jest to, że wiele bibliotek klienta HTTP ma wbudowaną obsługę uwierzytelniania Digest i Basic, ale może utrudnić życie przy próbie ustawienia wartości surowej w polu nagłówka, podczas gdy wszystkie zapewniają łatwą obsługę plików cookie i będą zezwalają na mniej więcej jakąkolwiek wartość w nich.

Question 3

W przypadku zapytania CROSS ORIGIN przeczytaj to:

Zmierzyłem się z taką sytuacją i na początku zdecydowałem się użyć Authorizationnagłówka, a później usunąłem go po rozwiązaniu następującego problemu.

AuthorizationNagłówek jest uważany za niestandardowy nagłówek. Jeśli więc żądanie między domenami jest Autorizationwysyłane z ustawionym nagłówkiem, przeglądarka najpierw wysyła żądanie inspekcji wstępnej . Żądanie inspekcji wstępnej jest żądaniem HTTP metodą OPTIONS, to żądanie usuwa wszystkie parametry z żądania. Twój serwer musi odpowiedzieć Access-Control-Allow-Headersnagłówkiem zawierającym wartość Twojego niestandardowego nagłówka ( Authorizationnagłówka).

Tak więc dla każdego żądania wysyłanego przez klienta (przeglądarkę) było wysyłane przez przeglądarkę dodatkowe żądanie HTTP (OPCJE). To pogorszyło wydajność mojego interfejsu API. Powinieneś sprawdzić, czy dodanie tego nie obniży wydajności. Aby obejść ten problem, wysyłam tokeny w parametrach http, co, jak wiem, nie jest najlepszym sposobem, ale nie mogłem pójść na kompromis z wydajnością.

Question 4

Jest to trochę przestarzałe, ale mogą być inni szukający odpowiedzi na to samo pytanie. Powinieneś pomyśleć o tym, jakie przestrzenie ochronne mają sens dla twoich interfejsów API. Na przykład możesz chcieć zidentyfikować i uwierzytelnić dostęp aplikacji klienckich do interfejsów API, aby ograniczyć ich użycie do znanych, zarejestrowanych aplikacji klienckich. W takim przypadku możesz użyćBasicschemat uwierzytelniania z identyfikatorem klienta jako identyfikatorem użytkownika i wspólnym sekretem klienta jako hasłem. Nie potrzebujesz zastrzeżonych schematów uwierzytelniania, po prostu jasno określ jeden (e), które mają być używane przez klientów dla każdej przestrzeni ochrony. Wolę tylko jeden dla każdej przestrzeni ochrony, ale standardy HTTP dopuszczają zarówno wiele schematów uwierzytelniania w każdej odpowiedzi nagłówka WWW-Authenticate, jak i wiele nagłówków WWW-Authenticate w każdej odpowiedzi; będzie to mylące dla klientów API, których opcji użyć. Bądź spójny i przejrzysty, wtedy będą używane Twoje interfejsy API.

Question 5

Nie radziłbym używać uwierzytelniania HTTP z niestandardowymi nazwami schematów. Jeśli czujesz, że masz coś z zastosowania ogólnego, to można zdefiniować nowy system, choć. Szczegółowe informacje można znaleźć pod adresem http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 .

Question 6

Prosimy spróbować poniżej na listonoszu: -

Przykładowa sekcja nagłówka działa dla mnie.

Autoryzacja: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU

Answer 1

Muszę uwierzytelnić klienta, kiedy wysyła żądanie do API. Klient ma API-token i myślałem o użyciu standardowego Authorizationnagłówka do wysłania tokena na serwer.

Normalnie ten nagłówek jest używany do Basici Digestuwierzytelniania. Ale nie wiem, czy mogę dostosować wartość tego nagłówka i użyć niestandardowego schematu uwierzytelniania, np .:

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

Poleciłbyś to czy nie? Czy jest lepsze podejście do wysyłania tokena?

Answer 2

Możesz tworzyć własne niestandardowe schematy uwierzytelniania, które używają Authorization:nagłówka - na przykład tak działa OAuth .

Z reguły jeśli serwery lub serwery proxy nie rozumieją wartości standardowych nagłówków, zostawiają je w spokoju i ignorują. To tworzenie własnych kluczy nagłówków , które często mogą dawać nieoczekiwane rezultaty - wiele serwerów proxy usuwa nagłówki z nazwami, których nie rozpoznają.

To powiedziawszy, prawdopodobnie lepszym pomysłem jest użycie plików cookie do przesyłania tokena, a nie Authorization:nagłówka, z tego prostego powodu, że pliki cookie zostały wyraźnie zaprojektowane do przenoszenia wartości niestandardowych, podczas gdy specyfikacja wbudowanych metod uwierzytelniania HTTP tak naprawdę nie mówi tak czy inaczej - jeśli chcesz zobaczyć, co dokładnie mówi, zajrzyj tutaj .

Inną kwestią jest to, że wiele bibliotek klienta HTTP ma wbudowaną obsługę uwierzytelniania Digest i Basic, ale może utrudnić życie przy próbie ustawienia wartości surowej w polu nagłówka, podczas gdy wszystkie zapewniają łatwą obsługę plików cookie i będą zezwalają na mniej więcej jakąkolwiek wartość w nich.

Answer 3

10

Miło słyszeć, jak działa OAuth. Nie wiem, czy używanie plików cookie upraszcza implementację klienta. O ile Twoim klientem nie jest przeglądarka, wtedy zasady pracy z plikami cookie (ścieżka, data ważności itp.) Są bardziej skomplikowane do zaimplementowania w kliencie niż tylko pamiętanie o ustawieniu pola nagłówka. Większość bibliotek klienta sprawia, że ustawienie poprawnych nagłówków jest dość proste.

Thomas Watson,

Answer 4

2

@ThomasWatson Chociaż nie mogę się z tobą nie zgodzić co do zakresu plików cookie, to nie powinno mieć tutaj znaczenia. Zakres uwierzytelniania HTTP (przy użyciu Authorization:nagłówka) dotyczy domeny. Oznacza to, że jeśli ustawisz domenę pliku cookie na „ta domena” i ścieżkę do „/”, zakres ten będzie identyczny jak w przypadku uwierzytelniania HTTP. Jednak to naprawdę zależy od ciebie - ale jak wskazuje Julian Reschke, prawdopodobnie nie powinieneś definiować nowego schematu uwierzytelniania, chyba że ty feel that you have something of generic use- coś, co mogłoby zostać użyte w innej aplikacji.

DaveRandom,

Answer 5

8

W przypadku zapytania CROSS ORIGIN przeczytaj to:

Zmierzyłem się z taką sytuacją i na początku zdecydowałem się użyć Authorizationnagłówka, a później usunąłem go po rozwiązaniu następującego problemu.

AuthorizationNagłówek jest uważany za niestandardowy nagłówek. Jeśli więc żądanie między domenami jest Autorizationwysyłane z ustawionym nagłówkiem, przeglądarka najpierw wysyła żądanie inspekcji wstępnej . Żądanie inspekcji wstępnej jest żądaniem HTTP metodą OPTIONS, to żądanie usuwa wszystkie parametry z żądania. Twój serwer musi odpowiedzieć Access-Control-Allow-Headersnagłówkiem zawierającym wartość Twojego niestandardowego nagłówka ( Authorizationnagłówka).

Tak więc dla każdego żądania wysyłanego przez klienta (przeglądarkę) było wysyłane przez przeglądarkę dodatkowe żądanie HTTP (OPCJE). To pogorszyło wydajność mojego interfejsu API. Powinieneś sprawdzić, czy dodanie tego nie obniży wydajności. Aby obejść ten problem, wysyłam tokeny w parametrach http, co, jak wiem, nie jest najlepszym sposobem, ale nie mogłem pójść na kompromis z wydajnością.

Abhishek Kumar
źródło

Rozważam również wysłanie mojego sessionID w parametrach http. Dlaczego mówisz, że to nie jest najlepszy sposób? Wydaje się, że ma tę zaletę, że jest odporny na zdejmowanie nagłówków przez zaporę ogniową, a także przed degradacją wydajności krzyżowej. Jakie są jego wady?

grzm

1

Wadą jest tylko w przypadku żądania GET. Musiałem uwierzytelnić użytkownika przy użyciu moich Authorization token(poufnych danych) dla mojej aplikacji. Z tego samego powodu nie powinniśmy wysyłać wrażliwych danych w GET, nie powinniśmy używać tokena autoryzacyjnego w params. Zgodnie z w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 „Protokół HTTP NIE POWINIEN używać formularzy opartych na GET do przesyłania poufnych danych”.

Abhishek Kumar

Możesz przechowywać token w plikach cookie, jeśli nie lubisz nagłówków. (Nie myl tokena z identyfikatorem sesji). Zauważ, że przez PUT i DELETE i tak wyśle OPCJE ... Należy pamiętać, że przez większość czasu używasz klienta REST po stronie serwera, a przeglądarka nie jest uważana za bardzo dobrego klienta REST.

inf3rno

Answer 6

Rozważam również wysłanie mojego sessionID w parametrach http. Dlaczego mówisz, że to nie jest najlepszy sposób? Wydaje się, że ma tę zaletę, że jest odporny na zdejmowanie nagłówków przez zaporę ogniową, a także przed degradacją wydajności krzyżowej. Jakie są jego wady?

grzm

Answer 7

1

Wadą jest tylko w przypadku żądania GET. Musiałem uwierzytelnić użytkownika przy użyciu moich Authorization token(poufnych danych) dla mojej aplikacji. Z tego samego powodu nie powinniśmy wysyłać wrażliwych danych w GET, nie powinniśmy używać tokena autoryzacyjnego w params. Zgodnie z w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 „Protokół HTTP NIE POWINIEN używać formularzy opartych na GET do przesyłania poufnych danych”.

Abhishek Kumar

Answer 8

Możesz przechowywać token w plikach cookie, jeśli nie lubisz nagłówków. (Nie myl tokena z identyfikatorem sesji). Zauważ, że przez PUT i DELETE i tak wyśle OPCJE ... Należy pamiętać, że przez większość czasu używasz klienta REST po stronie serwera, a przeglądarka nie jest uważana za bardzo dobrego klienta REST.

inf3rno

Answer 9

Jest to trochę przestarzałe, ale mogą być inni szukający odpowiedzi na to samo pytanie. Powinieneś pomyśleć o tym, jakie przestrzenie ochronne mają sens dla twoich interfejsów API. Na przykład możesz chcieć zidentyfikować i uwierzytelnić dostęp aplikacji klienckich do interfejsów API, aby ograniczyć ich użycie do znanych, zarejestrowanych aplikacji klienckich. W takim przypadku możesz użyćBasicschemat uwierzytelniania z identyfikatorem klienta jako identyfikatorem użytkownika i wspólnym sekretem klienta jako hasłem. Nie potrzebujesz zastrzeżonych schematów uwierzytelniania, po prostu jasno określ jeden (e), które mają być używane przez klientów dla każdej przestrzeni ochrony. Wolę tylko jeden dla każdej przestrzeni ochrony, ale standardy HTTP dopuszczają zarówno wiele schematów uwierzytelniania w każdej odpowiedzi nagłówka WWW-Authenticate, jak i wiele nagłówków WWW-Authenticate w każdej odpowiedzi; będzie to mylące dla klientów API, których opcji użyć. Bądź spójny i przejrzysty, wtedy będą używane Twoje interfejsy API.

Answer 10

2

Nie radziłbym używać uwierzytelniania HTTP z niestandardowymi nazwami schematów. Jeśli czujesz, że masz coś z zastosowania ogólnego, to można zdefiniować nowy system, choć. Szczegółowe informacje można znaleźć pod adresem http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 .

Julian Reschke
źródło

Dokument, do którego ma być odsyłacz, to wersja robocza protokołu HTTP / 1.1. Próbowałem zajrzeć do ostatecznego standardu i nie mogę nic znaleźć w tym, że muszę zarejestrować własne schematy. Czy nie mogło to być tak, że w trakcie tworzenia projektu chcieli znaleźć i uzgodnić domyślne schematy?

Thomas Watson,

Thomas, dokument, do którego się odwołałem, to wersja RFCs 2616/7 (która nie miała rejestru schematów). Jest w toku, ale zbliża się do zakończenia.

Julian Reschke,

Answer 11

Dokument, do którego ma być odsyłacz, to wersja robocza protokołu HTTP / 1.1. Próbowałem zajrzeć do ostatecznego standardu i nie mogę nic znaleźć w tym, że muszę zarejestrować własne schematy. Czy nie mogło to być tak, że w trakcie tworzenia projektu chcieli znaleźć i uzgodnić domyślne schematy?

Thomas Watson,

Answer 12

Thomas, dokument, do którego się odwołałem, to wersja RFCs 2616/7 (która nie miała rejestru schematów). Jest w toku, ale zbliża się do zakończenia.

Julian Reschke,

Answer 13

1

Prosimy spróbować poniżej na listonoszu: -

Przykładowa sekcja nagłówka działa dla mnie.

Autoryzacja: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU

Madan Dale
źródło

1

Czy naprawdę wysyłasz hasło / hash w JWT? To jest prosty base64.

Zachar

1

@Zakhar: dość typową praktyką w przypadku SPA jest hermetyzacja całej sesji użytkownika w JWT (ponieważ jest to kompletny dokument json), eliminując potrzebę przechowywania sesji po stronie serwera.

cowbert

@cowbert: Nie jestem pewien, czy typowe jest hermetyzowanie czegoś więcej niż pewnego rodzaju tokena sesji w JWT (zobacz na przykład ten post ).

Alexander Abakumov

1

@AlexanderAbakumov ten artykuł pełen wprowadzających w błąd, dostał kilka punktów, ale wiele z jego punktów nie ma sensu, a niektóre z nich po prostu przeciwstawia się bez powodu, mogę powiedzieć, że po prostu uwielbia ciasteczka i myślę, że potrzebuje trochę od Bakery i naprawiam jego artykuł, zdarzało mi się wiele sytuacji, że korzystałem z ciasteczek i marnowałem dni pracy, JWT z localStorage zaoszczędził mi wiele bólu głowy i czasu, to tylko 2 godziny pracy i huk, nigdy więcej go nie odwiedzę. Zastanawiam się, czy kiedykolwiek opracował aplikację mobilną, wypróbował przeglądarki z bardzo restrykcyjnymi regułami bezpieczeństwa i tak dalej.

Al-Mothafar

@ Al-Mothafar: będę wdzięczny jeśli rozwinąć swoich stwierdzeń, takich jak that article full of misleadings, a lot of his points does not make senseitp w jakiś sposób (to znaczy, to chyba coś poza komentarzu tutaj). Może mógłbyś napisać odpowiedź lub wpis na blogu? Porównanie argumentów byłoby naprawdę interesujące.

Alexander Abakumov

Answer 14

1

Czy naprawdę wysyłasz hasło / hash w JWT? To jest prosty base64.

Zachar

Answer 15

1

@Zakhar: dość typową praktyką w przypadku SPA jest hermetyzacja całej sesji użytkownika w JWT (ponieważ jest to kompletny dokument json), eliminując potrzebę przechowywania sesji po stronie serwera.

cowbert

Answer 16

@cowbert: Nie jestem pewien, czy typowe jest hermetyzowanie czegoś więcej niż pewnego rodzaju tokena sesji w JWT (zobacz na przykład ten post ).

Alexander Abakumov

Answer 17

1

@AlexanderAbakumov ten artykuł pełen wprowadzających w błąd, dostał kilka punktów, ale wiele z jego punktów nie ma sensu, a niektóre z nich po prostu przeciwstawia się bez powodu, mogę powiedzieć, że po prostu uwielbia ciasteczka i myślę, że potrzebuje trochę od Bakery i naprawiam jego artykuł, zdarzało mi się wiele sytuacji, że korzystałem z ciasteczek i marnowałem dni pracy, JWT z localStorage zaoszczędził mi wiele bólu głowy i czasu, to tylko 2 godziny pracy i huk, nigdy więcej go nie odwiedzę. Zastanawiam się, czy kiedykolwiek opracował aplikację mobilną, wypróbował przeglądarki z bardzo restrykcyjnymi regułami bezpieczeństwa i tak dalej.

Al-Mothafar

Answer 18

@ Al-Mothafar: będę wdzięczny jeśli rozwinąć swoich stwierdzeń, takich jak that article full of misleadings, a lot of his points does not make senseitp w jakiś sposób (to znaczy, to chyba coś poza komentarzu tutaj). Może mógłbyś napisać odpowiedź lub wpis na blogu? Porównanie argumentów byłoby naprawdę interesujące.

Alexander Abakumov

Dostosuj nagłówek HTTP autoryzacji

Odpowiedzi: