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

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

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

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

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

73
api authorization http http-headers rest

5 ответов

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

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

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

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

45

в случае ПЕРЕКРЕСТНОЕ ПРОИСХОЖДЕНИЕ просьба прочитать это:

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

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

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

7

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

4

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

1

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

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

авторизация: JWT

0