Налаштуйте заголовок HTTP Authorization

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 (шлях, термін дії тощо) є більш складними для реалізації в клієнті, ніж просто запам'ятовування встановлення поля заголовка. Більшість клієнтських бібліотек дозволяє досить просто встановити правильні заголовки.
— Thomas Watson,
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-запит (ОПЦІЇ). Це погіршило роботу мого API. Вам слід перевірити, чи додавання цього погіршує вашу продуктивність. Як обхідний шлях я надсилаю маркери в параметрах http, що, на мою думку, не найкращий спосіб зробити це, але я не міг піти на компроміс із продуктивністю.

— Абхішек Кумар
джерело
Я також розглядаю можливість просто надіслати свій sessionID у http params. Чому ви кажете, що це не найкращий спосіб? Здається, це має перевагу надійності проти загороджувальних заголовків брандмауерів, а також проти погіршення продуктивності перехресного джерела. Які його недоліки?
— удар
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. Я намагався розглянути остаточний стандарт і не можу знайти нічого про те, що мені доводиться реєструвати власні схеми. Чи не могло це бути просто так, що під час складання проекту вони хотіли знайти та узгодити схеми за замовчуванням?
— Thomas Watson,
Томасе, документ, на який я посилався, є переглядом RFC 2616/7 (який не мав реєстру схем). Це незавершене виробництво, але наближається до завершення.
— Джуліан Решке
1

Будь ласка, спробуйте нижче на листоноші: -

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

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

— Мадан Дейл
джерело
1
Ви справді надсилаєте пароль / хеш у JWT? Це проста база64.
— Захар,
1
@Zakhar: досить типовою практикою для SPA є інкапсуляція всієї сесії користувача в JWT (оскільки це повний документ json), усуваючи необхідність зберігання сеансів на стороні сервера.
— cowbert
@cowbert: Я не впевнений, що типово інкапсулювати щось більше, ніж якийсь маркер сеансу в JWT (див., наприклад, цей пост ).
— Олександр Абакумов
1
@AlexanderAbakumov у цій статті, сповненій оманливих поглядів, він отримав деякі бали, але багато його пунктів не має сенсу, і деякі з них він просто проти без будь-якої причини, я можу сказати, що він просто любить печиво, і я думаю, що йому потрібно отримати Випікаючи і виправляючи його статті, у мене було багато ситуацій, що я використовував кукі і марно витрачав дні роботи, JWT з localStorage заощадили мені багато головного болю і часу, це всього 2 години роботи і вибуху, більше ніколи його не відвідувати. Цікаво, чи розробляв він коли-небудь мобільний додаток, не пробував браузери з жорстко обмеженими правилами безпеки тощо.
— Аль-Мотафар
@ Аль-Mothafar: Я був би вдячний , якщо ви розширити ваші заяви , як 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.