Спеціальний заголовок авторизації HTTP

124

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

Чи буде щось подібне дійсним і дозволеним відповідно до специфікації: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

Перша частина другого рядка (перед ':') - це ключ API, друга частина - хеш рядка запиту.

— NRaf
джерело

133

Формат, визначений в RFC2617, є credentials = auth-scheme #auth-param. Отже, погоджуючись з fumanchu, я думаю, що виправлена схема авторизації виглядала б так

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

Де FIRE-TOKENсхема і дві пари ключ-значення - це параметри автентичності. Хоча я вважаю, що цитати необов’язкові (з Додатку Б до 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 (у коментарі до його відповіді), пояснює, чому введення спеціального заголовка додає додатковий тягар тепер, коли потрібно вручну правильно встановити кеш-контроль.

— Джон-Ерік

4

Крім того, якщо ви робите запит перехресного походження через веб-переглядач, ви зараз перебуваєте на території перед польотом саме через користувацький заголовок, де ви інакше могли його уникнути. Для певних додатків ці запити складаються.

— Віль Мур III

31

Величезне не для спеціальних заголовків аутентифікації. Стандартний Authorizationзаголовок із власною спеціальною схемою повинен бути більш ніж достатнім. Крім того, ви уникаєте запитів про вихід до польоту, як вказує @wilmoore. Спеціальні схеми не заважають жодному досить сучасному серверу HTTP, про який я знаю, плюс якщо ви використовуєте власну схему, вам доведеться її самостійно проаналізувати - жодна бібліотека не повинна суперечити (інакше бібліотека написана погано).

— Les Hazlewood

7

Важливою причиною для передачі облікових даних у Authorizationзаголовку, а не у власному заголовку, є те, що проксі та реєстратори знають, що вони сприймають інформацію як чутливу.

— Ерон Райт

15

Ні, це не є дійсним виробництвом згідно з визначенням "облікових даних" у RFC 2617 . Ви даєте дійсну схему auth, але значення auth-param повинні мати форму token "=" ( token | quoted-string )(див. Розділ 1.2), і ваш приклад не використовує "=" таким чином.

— фуманчу
джерело

1

Це не правильно. Приклад формату див. На сторінці 5 документа: Авторизація: Основні QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

Це правда. Але , як tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 каже, «" b64token "позначення було введено для сумісності з існуючими системами аутентифікації і може бути використана тільки один раз в виклик / облікові дані. Таким чином, нові схеми повинні використовувати синтаксис "auth-param", тому що в іншому випадку подальше розширення буде неможливим ". Дивіться також дискусію з кешу, що стосується створення автентичності в користувацьких заголовках.

— фуманчу

9

Старе питання я знаю, але для допитливих:

Вірите чи ні, ця проблема була вирішена ~ 2 десятиліття тому за допомогою HTTP BASIC, який передає значення як base64, закодоване ім'я користувача: пароль. (Див. Http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Ви можете зробити те саме, щоб приклад став вище:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— Майк Маркаччі
джерело

4

Я б радив проти цієї відповіді, оскільки, за коментарем до іншої відповіді тут , позначення, які тут використовуються, відповідають сумісності з існуючими схемами і не рекомендуються для нових розширень.

— Whymarrh