Podstawowe uwierzytelnianie HTTP i tokenów okaziciela

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?

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

curl -i http://username:password@dev.myapp.com/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"

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).

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.

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

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.

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.

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.