Пользовательский заголовок авторизации HTTP

124

Мне было интересно, допустимо ли помещать пользовательские данные в заголовок авторизации HTTP. Мы разрабатываем RESTful API, и нам может потребоваться способ указать собственный метод авторизации. В качестве примера назовем это FIRE-TOKENаутентификацией.

Будет ли что-то вроде этого действительным и разрешенным согласно спецификации: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

Первая часть второй строки (перед ':') - это ключ API, вторая часть - это хэш строки запроса.

http rest header authorization NRaf
источник

Ответы:

133

Формат, определенный в RFC2617, - credentials = auth-scheme #auth-param. Итак, согласившись с fumanchu, я думаю, что исправленная схема авторизации будет выглядеть так:

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

Где FIRE-TOKENсхема, а две пары ключ-значение - параметры аутентификации. Хотя я считаю, что цитаты необязательны (из Приложения B к p7-auth-19) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

Я считаю, что это соответствует последним стандартам, уже используется (см. Ниже) и предоставляет формат «ключ-значение» для простого расширения (если вам нужны дополнительные параметры).

Некоторые примеры этого синтаксиса auth-param можно увидеть здесь ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

StarTrekRedneck
источник
4
Другой пример - простой API хранилища Amazon .
епископ
18

Поместите его в отдельный настраиваемый заголовок.

Перегрузка стандартных заголовков HTTP, вероятно, вызовет больше путаницы, чем она того стоит, и нарушит принцип наименьшего удивления . Это также может привести к проблемам взаимодействия для ваших клиентских программистов API, которые хотят использовать готовые наборы инструментов, которые могут работать только со стандартной формой типичных заголовков HTTP (например, Authorization).

Брайан Келли
источник
3
Это может быть труднее, чем кажется. Ссылка, которую предоставляет fumanchu (в комментарии к его ответу), объясняет, почему введение настраиваемого заголовка добавляет дополнительное бремя, поскольку теперь необходимо вручную правильно настроить Cache-Control.
Джон-Эрик,
4
Кроме того, если вы делаете запрос на другой источник через браузер, вы теперь находитесь на предполетной территории только из-за настраиваемого заголовка, которого в противном случае можно было бы избежать. Для некоторых приложений эти запросы складываются.
Wil Moore III
31
Огромное нет настраиваемым заголовкам аутентификации. Стандартного Authorizationзаголовка с вашей собственной схемой должно быть более чем достаточно. Кроме того, вы избегаете предполетных запросов Origin, как указывает @wilmoore. Пользовательские схемы не мешают работе какого-либо достаточно современного HTTP-сервера, о котором я знаю, плюс, если вы используете свою собственную схему, вам придется разбирать ее самостоятельно - никакая библиотека не должна конфликтовать (иначе библиотека написана плохо).
Les Hazlewood,
7
Хорошая причина для передачи учетных данных в Authorizationзаголовке, а не в настраиваемом заголовке, заключается в том, что прокси и регистраторы знают, что информация должна рассматриваться как конфиденциальная.
Эрон Райт
15

Нет, это недопустимая продукция согласно определению «учетных данных» в RFC 2617 . Вы указываете действительную схему аутентификации, но значения параметров аутентификации должны иметь форму token "=" ( token | quoted-string )(см. Раздел 1.2), и в вашем примере "=" таким образом не используется.

fumanchu
источник
1
Это не так. Пример формата см. На странице 5 документа: Авторизация: Базовый QWxhZGRpbjpvcGVuIHNlc2FtZQ ==
NRaf
11
Это правда. Но , как tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 говорит, «„b64token“обозначение было введено для совместимости с существующими системами аутентификации и может быть использована только один раз в проблема / учетные данные. Таким образом, новые схемы должны использовать синтаксис auth-param вместо этого, потому что в противном случае будущие расширения будут невозможны ». См. Также обсуждение кеша относительно выполнения аутентификации в пользовательских заголовках.
fumanchu
9

Старый вопрос я знаю, но для любопытных:

Вы не поверите, но эта проблема была решена ~ 2 десятилетия назад с помощью HTTP BASIC, который передает значение как имя пользователя: пароль в кодировке base64. (См. Http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Вы можете сделать то же самое, чтобы приведенный выше пример выглядел так:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
Майк Маркаччи
источник
4
Я бы не советовал этот ответ, поскольку, согласно комментарию к другому ответу здесь , используемые здесь обозначения предназначены для совместимости с существующими схемами и не рекомендуются для новых расширений.
Whymarrh