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

Question

[MeGaBoJIbT]

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

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

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

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

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

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

Ну и да, все понимают что велосипеды лучше не писать, но *исторически сложившиеся* особенности приложения требуют кое где повелосипедить к сожалению.
Бек там шарповый, но я в него не лезу поэтому больше сказать с ходу не могу. Так что это такая хитрометка чтобы вопрос побольше увидело)

Comments

[sim3x]

Учтите, что большая часть проблем с токенами находится не на стороне браузера, а на строне фильтров и прокси, которые распространены в корпоративном секторе и которые криво настраивают

[MeGaBoJIbT]

sim3x, это понятно, но у нас приложение не б2б с блекджеком и банками.

Вы имели в виду, что смысл первого варианта в том числе в том что прокси режут заголовки а url обычно не режут?
Спасибо, об этом аргументе я не подумал. Впрочем я вижу как можно срезать кастомный заголовок случайно, но Authorisation чтобы срезать надо постараться вероятно.

В любом случае приложение расчитано скорее на юзеров-физиков а не на серьезный бизнес с упоротыми безопасниками.

[MeGaBoJIbT]

btw как в этом интерфейсе посмотреть дифф между редакциями, а то я вижу что Вы поправили, а тчо не вижу)

[sim3x]

MeGaBoJIbT, Да
Урл режут в последнюю очередь

Чем проще стандарт будете использовать - тем лучше

[Odrin]

Сейчас стандарт де-факто - это jwt токены с передачей через заголовок, Authorization: Bearer {token}. В .net есть поддержка из коробки для всего этого.

Answer 1

[Степан И]

Заголовок Authorisation является стандартом. В рамках него уже указывается схема аутентификации.

Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.
Пример 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 более чем достаточно. Мы у себя вместо логина передаем ключ авторизации и пустой пароль. Согласен что коряво.

Comments

[Odrin]

И каким образом все вышеперечисленное относится к передаче токена?

[Владислав]

Для передачи только ключа авторизации придумали:
Authorization: Bearer <token>

[Степан И]

Владислав Фурсов, спасибо!

Answer 2

[motomac]

В спецификации OAuth 2.0 (если вы его используете) явно указывается формат:

Authorization: Bearer <token>

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

Думаю, не лишним будет следовать ему.

Answer 3

[Alex McArrow]

Имхо третий вариант наиболее удобный. Тело запроса содержит только данные, при этом не передается данных в GET-части запроса (как в первом варианте).
+ третий вариант по сравнению с простой авторизацией позволяет накидать в заголовки что угодно (дополнительные параметры - если вдруг понадобится)

Comments

[MeGaBoJIbT]

Не семантичнее ли что попало кидать в отдельный кастомный заголовок а авторизацию оставить для авторизации?

[Alex McArrow]

MeGaBoJIbT, я так полагаю тут не идет вопрос об basic-authorization. тут скорее всего что-то типа:

GET /something HTTP/1.1
X-API-Key: abcdef12345

[MeGaBoJIbT]

Alex McArrow, ок, подумав соглашусь что так семантичнее если основная цель API - внешнее использование.

У нас это побочная цель, грубо говоря дать доступ к админке некоторому числу доверенных партнеров, а не большому числу кого попало. Поэтому работать с ними как с обычными юзерами мы не обломаемся пока.

Но я об этом не подумал, аргумент хороший.

[Растишка]

MeGaBoJIbT, Почему для внешнего использования лучше 31 вар?
У каждого юзера свой логин/пароль на basic http auth.
Схема рабочая и семантичная.

[Alex Wells]

Alex McArrow, вы, как юзер этого дела, сможете мне, дураку, обьяснить, в чем преимущество jwt или таких "токенов" над куки-сессиями?)

Поясню с моей точки зрения:
stateless jwt (не хранит инфу о юзере, лишь ссылку на нее) - ни чуть не лучше чем куки, так как в любом случае идет запрос к базе, и уже интегрированную систему хранения (куки) мы заменяем на свою (преимуществ почти ноль), зато возни - много.
stateful jwt (хранит инфу о юзере) - вообще не extendable, возни еще больше а преимуществ никаких (в месте, где может быть нужен авторизированный юзер, 100% используются другие методы связи с другой частью бека, а значит на практике никаких преимуществ), обновить нельзя, для девалидации токена - еще кучу велосипедов
api token - попросту небезопасно, не зря никто из крупных игроков, использующих эту систему, не дает доступа ни к одному важному эндпоинту. К тому же, он статичен, а значит это "недоделанный" stateless jwt.
api token + g2a - безопасно, но не работает для обычных юзеров (api-api будет работать класно, а вот с браузера - нет)

Итого пока кукисы - лучший вариант, как бы глупо это не звучало.

[MeGaBoJIbT]

Растишка, поясню свою мысль: есть допустим админское апи и два непустых множества юзеров пользующихся апи, "наши" которые делают обычно правильные, и которым можно дать по шапке если что и "не наши" которые вроде как доверенные но не совсем (партнеры всякие).

Соответственно есть кейс отличать наших юзеров от не наших чисто для отладки и быстрого анализа логов. (Понятно что для бизнеслогики это ненадежно).

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

Если одно из множеств пустое, проблемы не возникает. Если число "не наших" юзеров очень мало, то она почти не возникает.

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

[Alex McArrow]

Alex Wells, лично для меня их суть (JWT) - возможность передавать данные между сервисами. Как пример - данный ресурс самостоятелен, но позволяет авторизоваться пользователям Хабра под своими учетками. Такой алгоритм можно организовать через OpenID или JWT.
А по факту все зависит от среды применения.

• Сайт - пользователь = логин+пароль или соцсети через OpenID
  
• Сайт - API = токены или сессионный ключ на основании авторизации (логин+пароль)
  
• Сервис - сервис = токен +- проверка на ресурс источник запроса (IP или домен)
  

[Odrin]

Alex Wells, cookie - это для браузера, но клиент web-сервиса не всегда браузер. Городить поддержку cookie в своем http-клиенте как-то странно, когда есть более универсальный и удобный подход с jwt. Кроме того, cookie ограниченны одним доменом.

[Alex Wells]

Odrin, ну, в том же месте, где вы будете городить поддержку куки, там же будет и нагорожена поддержка jwt. Но в любом случае в 99% случаев будет использовано готовое решение, поддерживающие обе технологии из коробки (ну или почти).

А вот про один домен - весомый аргумент, согласен.

В любом случае спасибо за ответ, я почему то упустил момент с кросс-доменностью.

Answer 4

[ALIAKSANDR ZHALIAZOUSKI]

Всегда если позволено заказчиками использую 2 вариант. Минимум шагов. Прост и понятен

Answer 5

[Игорь Русинов]

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