Podstawowe uwierzytelnianie HTTP i tokenów okaziciela

115

Obecnie pracuję nad REST-API, które jest chronione przez HTTP-Basic dla środowiska programistycznego. Ponieważ prawdziwe uwierzytelnianie odbywa się za pomocą tokena, wciąż próbuję dowiedzieć się, jak wysłać dwa nagłówki autoryzacji.

Próbowałem tego:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

Mógłbym na przykład wyłączyć uwierzytelnianie HTTP dla mojego adresu IP, ale ponieważ zwykle pracuję w różnych środowiskach z dynamicznymi adresami IP, nie jest to dobre rozwiązanie. Więc coś mi brakuje?

Azngeek
źródło
2
Potrzebuję uwierzytelnienia przez HTTP Basic, ponieważ serwer Dev jest nim chroniony i potrzebuję uwierzytelniania opartego na tokenach dla interfejsu API. Ale ponieważ używam curl do testowania interfejsu API, potrzebuję sposobu na wysłanie obu nagłówków uwierzytelniania. Więc pierwszy (podstawowy) do przekazania HTTP Basic, a drugi (token) do uwierzytelnienia w mojej aplikacji. I tak, to moje własne dzieło.
Azngeek
1
Czy kiedykolwiek to rozgryzłeś? Dodaję nagrodę
Adam Waite
4
Cześć Adam, niestety nie. Teraz zmieniłem sposób działania uwierzytelniania, zmieniając nagłówek autoryzacji tokena na „x-auth”, który nie jest standardowym nagłówkiem.
Azngeek
1
Mój serwer nginx nie zaakceptuje nawet 2 nagłówków autoryzacji. Zwraca a 400 Bad request. Głupi.
Rudie
1
Co jest złego w używaniu niestandardowego nagłówka dla tokena API? Nie rozumiem, dlaczego ludzie tutaj "wyrzucili" używając HTTP Basic Auth, aby chronić swoje serwery programistyczne / przejściowe przed wzrokiem ciekawskich.
Sunil D.

Odpowiedzi:

68

Spróbuj tego, aby przekazać uwierzytelnianie podstawowe pod adresem URL:

curl -i http://username:[email protected]/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

Jeśli powyższy nie działa, to nie masz z tym nic wspólnego. Więc wypróbuj następujące alternatywy.

Możesz przekazać token pod inną nazwą. Ponieważ obsługujesz autoryzację z aplikacji. Możesz więc łatwo wykorzystać tę elastyczność do tego specjalnego celu.

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

Zauważ, że zmieniłem nagłówek na Application-Authorization. Więc z aplikacji złap token pod tym nagłówkiem i przetwórz to, co musisz zrobić.

Inną rzeczą, jaką możesz zrobić, to przejść tokenprzez POSTparametrów i weź wartość parametru od strony serwera. Na przykład przekazanie tokena z parametrem curl post:

-d "auth-token=mytoken123"
Sabuj Hassan
źródło
1
Witaj Sabuj, problem nie polega na tym, jak podajesz nazwę użytkownika i hasło, ale wiele nagłówków autoryzacji po prostu nie działa. Patrząc na specyfikacje ( ietf.org/rfc/rfc2617.txt ) widzę, że powinno to być możliwe. Ale jak również stwierdzono, "" Agent użytkownika MUSI wybrać jedno z wyzwań z najsilniejszym schematem autoryzacji, jaki rozumie i zażądać poświadczeń od użytkownika na podstawie tego wyzwania. "Tak jak napisałem 2 dni temu, musiałem przejść żeton do niestandardowego nagłówka, który jest absolutnie w porządku, gdy mamy do czynienia z niestandardowych architektur.
Azngeek
5
@Azngeek Curl wysyła oba nagłówki autoryzacji podczas wykonywania zadania. Musisz zająć się tym od końca swojego serwera. Po prostu uruchom polecenie curl z obydwoma nagłówkami z -vparam. Przekonasz się, że jest wysyłany Authorization: Basic Ym9zY236Ym9zY28=, Authorization: Bearer mytoken123w nagłówku żądania. Od strony serwera, jeśli sprawdzisz, zobaczysz, że masz taki nagłówek Authorization Authorization: Basic Ym9zY236Ym9zY28=, Bearer mytoken123oddzielony przecinkiem. Więc pomyślałem, że powinienem zaproponować ci zastępców.
Sabuj Hassan,
34

Standard ( https://tools.ietf.org/html/rfc6750 ) mówi, że możesz użyć:

  • Parametr treści zakodowany w formularzu: Autoryzacja: Bearer mytoken123
  • Parametr zapytania URI: access_token = mytoken123

Możliwe jest więc przekazanie wielu tokenów okaziciela z URI, ale robienie tego jest odradzane (patrz sekcja 5 w standardzie).

Janek Olszak
źródło
4

Jeśli używasz zwrotnego serwera proxy, takiego jak nginx, możesz zdefiniować niestandardowy token, taki jak X-API-Token .

W nginx przepisałbyś go tak, aby zewnętrzny serwer proxy (pozostałe api) był po prostu auth:

proxy_set_header Authorization $http_x_api_token;

... podczas gdy nginx może użyć oryginalnego nagłówka Authorization do sprawdzenia HTTP AUth.

strzępienie
źródło
3

Miałem podobny problem - uwierzytelnij urządzenie i użytkownika na urządzeniu. Użyłem Cookienagłówka obok Authorization: Bearer...nagłówka.

Iiridayn
źródło
Nie jest jasne, dlaczego głosowano przeciw. Natknąłem się na to pytanie, szukając odpowiedzi na powiązany problem - tak go rozwiązałem. CookieNagłówek jest już często wykorzystywane do uwierzytelniania.
Iiridayn
2

curl --anyauth

Instruuje curl, aby sam ustalił metodę uwierzytelniania i użył najbezpieczniejszej metody obsługiwanej przez witrynę zdalną. Odbywa się to najpierw wykonując żądanie i sprawdzając nagłówki odpowiedzi, co może spowodować wywołanie dodatkowej sieci w obie strony. Jest to używane zamiast ustawiania określonej metody uwierzytelniania, co można zrobić za pomocą --basic, --digest, --ntlm i --negotiate.

bbaassssiiee
źródło
1

Istnieje inne rozwiązanie do testowania interfejsów API na serwerze deweloperskim.

  • Zestaw HTTP Basic Authentication tylko dla tras internetowych
  • Pozostaw wszystkie trasy API wolne od uwierzytelniania

Konfiguracja serwera WWW dla nginxi Laravelwyglądałaby następująco:

    location /api {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;

        auth_basic "Enter password";
        auth_basic_user_file /path/to/.htpasswd;
    }

Authorization: Bearer wykona zadanie obrony serwera programistycznego przed robotami internetowymi i innymi niechcianymi użytkownikami.

Andrew Kolpakov
źródło
0

Z nginx możesz wysłać oba tokeny w ten sposób (nawet jeśli jest to niezgodne ze standardem):

Authorization: Basic basic-token,Bearer bearer-token

Działa to tak długo, jak podstawowy token jest pierwszy - nginx pomyślnie przekazuje go do serwera aplikacji.

Następnie musisz się upewnić, że aplikacja może poprawnie wyodrębnić Bearer z powyższego ciągu.

Lacho Tomov
źródło