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

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

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

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

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

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

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

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

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

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

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

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

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

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

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

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

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

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