@MeGaBoJIbT
js-обезъянка

Дизайн REST API: Как сейчас принято передавать авторизационный токен?

Дисклеймер: я тупой фронтэнд-жаваскриптер и делать это большей частью не мне. Но лучше спросить чем не спросить.

Сейчас мои коллеги переписывают авторизацию в одном веб-приложении.
Там restful json api, и предусматривается отдача часть api на использование внешним потребителям (доверенному списку а не всем подряд), то есть кросдоменность - нужна.
Теоретическая поддержка клиентами: браузеры, самый старый из которых IE11. Такой клиент давно есть и работает.
Мобильные устройства последних версий. Там ничего нет, только в планах и того кто мог бы что-то по этому поводу сказать тоже нет.

И возник у нас небольшой спор, как собственно передавать авторизационные токены?
Варианта собственно три, в порядке убывания встречаемости.
1). В url запроса по типу. /?auth_token=.
2). HTTP-заголовок Authorisation
3). Кастомный HTTP заголовок.

Первый вариант очень распространенный и популярный, но я не вполне понимаю почему. Единственное преимуещство этого варианта которое я вижу - это поддержка всяких JSONP костылей, которая нам вроде как и не нужна если у нас целевые клиенты умеют в кросдоменность без этого.

Второй вариант мне наиболее симпатичен, он для меня выглядит например посекьюрнее с точки зрения защиты от csrf и например необходимости контролировать не ушло ли чего лишнего например сторонним пикселям.
Третий вариант я не отметаю потому что так видел кое-где, но не очень понимаю нахрена

Собственно вопросы:
1. Где считается хорошей практикой передавать авторизационный токен в текущем 20огосподиуже18 году?
2. Какие есть преимущества у 1го варианта которых я не увидел? Правильно ли я понимаю что его держит инерция и соображения поддержки легаси в основном?
3. Есть ли какие-то грабли которые будут щекотать лоб при реализации второго варианта?

Ну и да, все понимают что велосипеды лучше не писать, но *исторически сложившиеся* особенности приложения требуют кое где повелосипедить к сожалению.
Бек там шарповый, но я в него не лезу поэтому больше сказать с ходу не могу. Так что это такая хитрометка чтобы вопрос побольше увидело)
  • Вопрос задан
  • 14173 просмотра
Пригласить эксперта
Ответы на вопрос 5
@micronull
Заголовок Authorisation является стандартом. В рамках него уже указывается схема аутентификации.

Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.
c27ac06373984352a1ebe2f6424cd9e9.png Пример HTTP аутентификации с использованием Basic схемы.

Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.

NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.

Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.
https://habrahabr.ru/company/dataart/blog/262817/

Свой заголовок имеет смысл создавать, если ни один из способов не подходит.
Но как правило Basic более чем достаточно. Мы у себя вместо логина передаем ключ авторизации и пустой пароль. Согласен что коряво.
Ответ написан
@motomac
В спецификации OAuth 2.0 (если вы его используете) явно указывается формат:

Authorization: Bearer <token>

https://tools.ietf.org/html/rfc6749#section-7.1

Думаю, не лишним будет следовать ему.
Ответ написан
Комментировать
AlexMcArrow
@AlexMcArrow
Люблю РНР, да я такой!
Имхо третий вариант наиболее удобный. Тело запроса содержит только данные, при этом не передается данных в GET-части запроса (как в первом варианте).
+ третий вариант по сравнению с простой авторизацией позволяет накидать в заголовки что угодно (дополнительные параметры - если вдруг понадобится)
Ответ написан
Всегда если позволено заказчиками использую 2 вариант. Минимум шагов. Прост и понятен
Ответ написан
Комментировать
Ваши вопросы по порядку:
1. Хорошей практикой считается передача http-заголовка Authorization (все известные мне методы: Basic auth, JWT token, Oauth2 предполагают его использование).
2. Одно из преимуществ, которые я вижу, это возможность быстро проверить какие либо результаты прямо в браузере, т.к. при использовании авторизации через http-заголовок, нужно использовать какой-либо инструмент для тестирования API. Но я бы добавил это только как альтернативный вариант авторизации, например только на тестовом сервере/в локальной среде, и не использовал в продакшене.
3. Никаких граблей со вторым вариантом не встречал, т.к. это стандартный заголовок. Предполагаю, что можно наткнуться на грабли с третьим вариантом, например нестандартные заголовки будут резаться какими-нибудь проксями, кешами.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы