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

81

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

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

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

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

api  http  rest  http-headers  authorization 
— Томас Уотсон
источник

Ответы:

51

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

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

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

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

— DaveRandom
источник
10
Приятно слышать, как работает OAuth. Я не уверен, что использование файлов cookie упрощает реализацию клиента. Если ваш клиент не является браузером, правила работы с файлами cookie (путь, срок действия и т. Д.) Сложнее реализовать на клиенте, чем просто не забыть установить поле заголовка. Большинство клиентских библиотек позволяют довольно просто установить правильные заголовки.
— Томас Уотсон
2
@ThomasWatson, хотя я не могу не согласиться с вами по поводу точек действия файлов cookie, здесь это не имеет особого значения. Объем HTTP-аутентификации (с использованием Authorization:заголовка) зависит от домена. Это означает, что если вы установите домен cookie на «этот домен» и путь к «/», он будет иметь ту же область действия, что и HTTP auth. Однако это действительно зависит от вас - но, как указывает Джулиан Решке, вам, вероятно, не следует определять новую схему аутентификации, если вы не feel that you have something of generic use- то, что можно было бы использовать в другом приложении.
— DaveRandom
8

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

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

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

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

— Абхишек Кумар
источник
Я также рассматриваю возможность просто отправить свой идентификатор сеанса в http params. Почему вы говорите, что это не лучший способ? Похоже, у него есть преимущество в надежности против брандмауэров, удаляющих заголовки, а также против снижения производительности между источниками. Какие у него недостатки?
— чт 01
1
Недостаток только в случае запроса GET. Мне пришлось аутентифицировать пользователя, используя мои Authorization token(конфиденциальные данные) для моего приложения. По той же причине мы не должны отправлять конфиденциальные данные в GET, мы не должны использовать токен авторизации в params. Согласно w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 «Протокол HTTP НЕ ДОЛЖЕН использовать формы на основе GET для отправки конфиденциальных данных».
— Абхишек Кумар,
Вы можете хранить токен в файлах cookie, если вам не нравятся заголовки. (Не путайте токен с идентификатором сеанса). Обратите внимание, что при PUT и DELETE он все равно отправит ОПЦИИ ... Имейте в виду, что большую часть времени вы используете клиент REST на стороне сервера, а браузер не считается очень хорошим клиентом REST.
— inf3rno
5

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

— Стив Дирборн
источник
2

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

— Джулиан Решке
источник
Документ, на который нужно ссылаться, представляет собой черновик HTTP / 1.1. Я пытался заглянуть в окончательный стандарт и ничего не нашел, что мне нужно зарегистрировать пользовательские схемы. Не могло ли быть так, что в процессе разработки они хотели найти и согласовать стандартные схемы?
— Томас Уотсон
Томас, документ, на который я ссылался, является редакцией RFC 2616/7 (в котором не было реестра схем). Он еще не завершен, но близок к завершению.
— Джулиан Решке
1

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

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

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

— Мадан Дейл
источник
1
Вы действительно отправляете пароль / хеш в JWT? Это простой base64.
— Захар
1
@Zakhar: довольно типичной практикой для SPA является инкапсуляция всего сеанса пользователя в JWT (поскольку это полный документ json), устраняя необходимость в хранилище сеанса на стороне сервера.
— Cowbert
@cowbert: Я не уверен, что это типично для инкапсуляции чего-то большего, чем какой-то токен сеанса в JWT (см., например, этот пост ).
— Александр Абакумов
1
@AlexanderAbakumov, эта статья полна заблуждений, он получил некоторые очки, но многие из его пунктов не имеют смысла, а некоторые из них он просто против без какой-либо причины, я могу сказать, что он просто любит печенье, и я думаю, что ему нужно получить немного от Выпечка и исправление его статьи, у меня было много ситуаций, когда я использовал файлы cookie и тратил дни работы впустую, JWT с localStorage сэкономил мне много головной боли и времени, это всего лишь 2 часа работы и бац, никогда не посещайте его снова. Интересно, разрабатывал ли он когда-нибудь мобильное приложение, пробовал ли браузеры с жестко ограниченными правилами безопасности и так далее.
— Аль-Мотафар
@ Аль-Мотафар: Буду признателен, если вы каким-то образом расширите свои утверждения, например that article full of misleadings, a lot of his points does not make senseи т. Д. ( То есть, вероятно, это что-то помимо комментария здесь). Может быть, вы могли бы написать ответ или написать в блоге? Было бы действительно интересно сравнить аргументы.
— Александр Абакумов
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.