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

68

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

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

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

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

Теги:
http-headers
rest
http
authorization

5 ответов

40
Лучший ответ

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

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

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

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

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

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

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

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

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

Поделиться
  • 0
    Я также рассматриваю возможность отправки моего sessionID в параметрах http. Почему вы говорите, что это не лучший способ? Похоже, что он обладает преимуществом надежности по отношению к брандмауэрам, удаляющим заголовки, а также к снижению производительности на разных источниках. Каковы его недостатки?
  • 1
    Недостаток только в случае запроса GET. Мне пришлось аутентифицировать пользователя, используя мой Authorization token (конфиденциальные данные) для моего приложения. По той же причине мы не должны отправлять конфиденциальные данные в GET, мы не должны использовать токен авторизации в параметрах. Согласно w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 «Протокол HTTP НЕ ДОЛЖЕН использовать формы GET для представления конфиденциальных данных».
Показать ещё 1 комментарий
4

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

Поделиться
1

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

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

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

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

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

Поделиться
  • 0
    Вы действительно отправляете пароль / хэш в JWT? Это простая base64.
  • 0
    @Zakhar: это довольно типичная практика для SPA - инкапсулировать весь пользовательский сеанс в JWT (так как это полный документ json), устраняя необходимость хранения сеанса на стороне сервера.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню