Настройте HTTP-заголовок авторизации

Question

Мне нужно аутентифицировать клиента, когда он отправляет запрос в API. У клиента есть API-токен, и я думал об использовании стандартного заголовка Authorization для отправки токена на сервер.

Обычно этот заголовок используется для аутентификации Basic и Digest. Но я не знаю, разрешено ли мне изменять значение этого заголовка и использовать собственную схему авторизации, например:

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

Вы бы порекомендовали это или нет? Или есть лучший подход к отправке токена?

Answer 1

Вы можете создавать свои собственные схемы аутентификации, которые используют заголовок Authorization: - например, так работает OAuth .

Как правило, если серверы или прокси-серверы не понимают значений стандартных заголовков, они оставляют их в покое и игнорируют их. Он создает свой собственный заголовок keys , который часто может привести к непредвиденным результатам - многие прокси будут удалять заголовки с именами, которые они не распознают.

Сказав это, возможно, лучше использовать куки для передачи токена, а не заголовок Authorization:, по той простой причине, что куки были явно предназначены для переноса пользовательских значений, тогда как спецификация для HTTP встроена Методы аутентификации на самом деле ничего не говорят - если вы хотите точно увидеть, что они говорят, посмотрите здесь .

Другой момент заключается в том, что во многих клиентских библиотеках HTTP есть встроенная поддержка Digest и Basic auth, но это может усложнить жизнь при попытке установить необработанное значение в поле заголовка, тогда как все они обеспечат простую поддержку куки-файлы и позволят получить более или менее любое значение в них.

Answer 2

В случае CROSS ORIGIN запрос читать это:

Я столкнулся с такой ситуацией, и сначала я решил использовать заголовок Authorization, а затем удалил его после решения следующей проблемы.

Authorization Заголовок считается пользовательским заголовком. Таким образом, если кросс-доменный запрос сделан с набором Autorization Header, браузер сначала отправляет предварительный запрос . Предварительный запрос - это HTTP-запрос метода OPTIONS, который удаляет все параметры из запроса. Ваш сервер должен ответить Access-Control-Allow-Headers Заголовок, имеющий значение вашего пользовательского заголовка (Authorization header).

Таким образом, для каждого запроса, отправляемого клиентом (браузером), браузер отправлял дополнительный HTTP-запрос (ОПЦИИ). Это ухудшило производительность моего API. Вы должны проверить, снижает ли это вашу производительность. В качестве обходного пути я отправляю токены в параметрах http, которые, как я знаю, не лучший способ сделать это, но я не могу пойти на компромисс с производительностью.

Answer 3

Это немного устарело, но могут быть и другие, которые ищут ответы на тот же вопрос.Вы должны подумать о том, какие пространства защиты имеют смысл для ваших API.Например, вы можете захотеть идентифицировать и аутентифицировать доступ клиентских приложений к вашим API, чтобы ограничить их использование известными зарегистрированными клиентскими приложениями.В этом случае вы можете использовать схему аутентификации Basic с идентификатором клиента в качестве идентификатора пользователя и общим секретным ключом клиента в качестве пароля.Вам не нужны проприетарные схемы аутентификации, просто четко указывайте те, которые будут использоваться клиентами для каждого пространства защиты.Я предпочитаю только один для каждого пространства защиты, но стандарты HTTP допускают как несколько схем аутентификации для каждого ответа заголовка WWW-Authenticate, так и несколько заголовков WWW-Authenticate в каждом ответе;это будет сбивать с толку клиентов API, какие варианты использовать.Будьте последовательны и понятны, тогда ваши API будут использованы.

Answer 4

Я бы рекомендовал не использовать HTTP-аутентификацию с именами пользовательских схем. Если вы чувствуете, что имеете что-то общее, вы можете определить новую схему. Подробнее см. http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3.

Answer 5

Пожалуйста, попробуйте ниже на почтальоне: -

В примере с заголовком сработайте для меня ..

Авторизация: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9..BkyB0LjKB4FIsCtnMyKx *5xZZ_5xZ_c5_cx_1Z5_cx_1Z5_ZZ_1Z5_ZZ_5ZZ_1Z5_ZZ_5ZZ_c5_1_5ZZ_1Z5_cx_1_5xc_p_1_1_5xc_p_1_1_5xc_t_1_5xc_c_t_1_5xc_c_1_5xc_c_1_5_5_c_1_1_5_1_1_5_1_1_1_5_1_1_5_5_1_155_5_155_5 *