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

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

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

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

В случае запроса CROSS ORIGIN прочтите следующее:

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

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

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

Ответ 3

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

Ответ 5

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

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

Авторизация: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjp bXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU