@kirill-93

Как сделать авторизацию между двумя api?

К нам в апи приходят запросы от клиента (spa на react). Один из запросов - запрос на получение статистики. Статистика хранится в MySQL тут же на сервере и перед ее отдачей мы проверяем, авторизован ли пользователь и имеет ли он доступ к этой статистике.
По мере роста объемов мы решили перевести статистику на отдельный сервер и отдельный домен. Кроме того, подключили туда ClickHouse, чтобы эффективнее обрабатывать данные.
Теперь встал вопрос, как делать проверку авторизованности. Цепочка получается такая:
client -> api -> statistics
То есть с клиента приходит запрос в апи, апи проверяет права пользователя и дёргает сервер со статистикой.
Теперь нужно сделать так, чтобы сервер со статистикой отдавал данные только серверу апи, чтобы никто посторонний не смог получить данные.
Какие тут варианты? Вот что приходит в голову:
1. Белый список адресов. Сервер статистики проверяет с какого айпи к нему пришел запрос и отдает его только в случае совпадения. Мне не нравится этот способ, потому что у нас несколько серверов, в том числе и резервные. Если мы будем докупать/менять сервера, то список нужно держать в голове.
2. Передавать какой-то секретный ключ с сервера АПИ и проверять его на сервере статистики. Этот вариант мне кажется наиболее удобным, но в каком виде его хранить и как передавать?
Посоветуйте, пожалуйста.
  • Вопрос задан
  • 357 просмотров
Решения вопроса 2
Wolfnsex
@Wolfnsex
Если не хочешь быть первым - не вставай в очередь!
2. Передавать какой-то секретный ключ с сервера АПИ и проверять его на сервере статистики. Этот вариант мне кажется наиболее удобным, но в каком виде его хранить и как передавать?
Видится мне, что это самый разумный вариант. Список адресов - не слишком надёжен и не особо логичен.

Как передавать - так же как и сам запрос, в виде параметра, заголовка или любой другой части запроса, которая в конечном итоге будет разбираться на сервере. Как хранить - мы обычно храним в ENV (переменных окружения) или конфигурационных файлах проекта.
Ответ написан
athacker
@athacker
Use client certificate authentication, Luke! Только колхозить подписание запросов не нужно, как рекомендует камрад Кирилл Горелов, достаточно просто TLS наладить. Заодно получите шифрованный канал данных. Если нативно сервер этого не умеет, можно на фронт поставить nginx (у вас же там наверняка какой-нибудь REST или что-нибудь такое, да?), который прекрасно умеет в аутентификацию по клиентским сертификатам.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
inoise
@inoise
Solutions Architect, AWS Certified, Serverless
Итак, читаем дружно что такое OpenId и OAuth2. Потом читаем про существование Identity Server. Если хочется все самим то на вскидку Keycloak, если хочется сервис то Auth0. В догонку читаем про токены JWT. Если не нравятся предложенные варианты то ищем аналоги. Идея в том что если есть несколько мест аутентификации то надо выносить аутентификацию отдельно. Жду глупых или умных вопросов в комментариях)
Ответ написан
@Kirill-Gorelov
С ума с IT
Мы сделали так.

С помощью подписей.
Есть открытый + закрытый ключ.
Закрытым ключом подписываем наши данные, отправляем серверу с открытым ключом.
На стороне api по открытым ключу ищем закрытый, то есть достоверный источник. Проверяем подпись. И если все ок, то пропускаем.
Есть класс на php и python, что бы можно было общаться в обе стороны, если разные языки.

Мы пока не жалуемся.
Ответ написан
xenozauros
@xenozauros
Админю, пишу на питоне, вот это вот все...
А почему просто не перевести служебный трафик в отдельную локалку/влан без прямого доступа из интернета?
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
Chenii Санкт-Петербург
от 1 500 до 3 500 usd.
AVC Advisory Москва
от 60 000 до 90 000 руб.
16 окт. 2019, в 17:12
300 руб./за проект
16 окт. 2019, в 17:11
3000 руб./за проект
16 окт. 2019, в 17:07
3800 руб./за проект