Базовая аутентификация HTTP и токена-носителя

В настоящее время я разрабатываю REST-API, защищенный HTTP-Basic для среды разработки. Поскольку настоящая аутентификация выполняется с помощью токена, я все еще пытаюсь понять, как отправить два заголовка авторизации.

Я пробовал это:

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

Я мог бы, например, отключить HTTP-аутентификацию для своего IP-адреса, но, поскольку я обычно работаю в разных средах с динамическими IP-адресами, это не лучшее решение. Так я что-то упускаю?

Попробуйте это, чтобы нажать базовую аутентификацию по URL-адресу:

curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

Если вышеперечисленное не работает, значит, вы не при чем. Поэтому попробуйте следующие варианты.

Вы можете передать токен под другим именем. Поскольку вы обрабатываете авторизацию из своего приложения. Таким образом, вы можете легко использовать эту гибкость для этой специальной цели.

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

Обратите внимание, я изменил заголовок на Application-Authorization. Итак, из вашего приложения перехватите токен под этим заголовком и обработайте то, что вам нужно сделать.

Еще одна вещь , которую вы можете сделать, чтобы пройти tokenчерез POSTпараметры и захватить значение параметра со стороны сервера. Например, передача токена с параметром curl post:

-d "auth-token=mytoken123"

Стандарт ( https://tools.ietf.org/html/rfc6750 ) говорит, что вы можете использовать:

• Закодированный в форме параметр тела: Авторизация: носитель mytoken123
• Параметр запроса URI: access_token = mytoken123

Таким образом, можно передать множество токенов-носителей с URI, но делать это не рекомендуется (см. Раздел 5 стандарта).

Если вы используете обратный прокси-сервер, такой как nginx между ними, вы можете определить собственный токен, например X-API-Token.

В nginx вы бы переписали его для восходящего прокси (вашего остального api), чтобы он был просто auth:

proxy_set_header Authorization $http_x_api_token;

... в то время как nginx может использовать исходный заголовок авторизации для проверки HTTP AUth.

У меня была аналогичная проблема - аутентифицировать устройство и пользователя на устройстве. Я использовал Cookieзаголовок рядом с Authorization: Bearer...заголовком.

curl --anyauth

Сообщает curl, чтобы он сам определил метод аутентификации и использовал наиболее безопасный, который, по утверждениям удаленного сайта, поддерживает. Для этого сначала выполняется запрос и проверяются заголовки ответов, что, возможно, вызывает дополнительный круговой обход сети. Это используется вместо установки определенного метода аутентификации, который вы можете сделать с помощью --basic, --digest, --ntlm и --negotiate.

Есть еще одно решение для тестирования API на сервере разработки.

• Установить HTTP Basic Authenticationтолько для веб-маршрутов
• Оставьте все маршруты API свободными от аутентификации

Конфигурация веб-сервера для nginxи Laravelбудет такой:

    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 будет выполнять работу по защите сервера разработки от поисковых роботов и других нежелательных посетителей.

С помощью nginx вы можете отправить оба токена следующим образом (хотя это и противоречит стандарту):

Authorization: Basic basic-token,Bearer bearer-token

Это работает до тех пор, пока первым является базовый токен - nginx успешно перенаправляет его на сервер приложений.

И затем вам нужно убедиться, что ваше приложение может правильно извлекать Bearer из указанной выше строки.