#breakfront_tooltips #breakfront_analysis_fails
ДОСТУП К ДАННЫМ В API
Чтобы подобраться к данным из API клиент, как правило, проходит два этапа: аутентификация и авторизация.
Аутентификация - это проверка подлинности пользователя (правильный логин и пароль, например). Очень часто клиент проходит аутентификацию и получает JWT-токен, с которым делает запросы к API разных сервисов. Сервисы проверяют подлинность и актуальность этого токена при каждом запросе. У токена задается время жизни, по прошествии которого токен надо обновить. Если токен неверный или “протух”, API ответит на вызов ошибкой.
Примечательно, что даже сервис, который сам не генерировал JWT-токен, имея соответсвующий ключ, может проверить подлинность и актуальность токена. Что делает эту технологию очень удобной в случае сервисно-ориентированной и микросервисной архитектуры: достаточно сделать один сервис аутентификации, который будет хранить данные клиентов, выдавать токены и заботиться о безопасности, а остальные сервисы будут иметь дело только с токенами.
Также в JWT-токене может быть какой-то payload, то есть “полезная нагрузка”: данные, которые можно передавать прямо в токене, сообщая что-то сервису. Например, там может быть id пользователя, его роль и доступы и пр. В интересах безопасности payload можно зашифровать. Но, например, в системах, работающих в контуре компании под VPN какие-то данные можно передавать открыто и тогда их легко получить сразу из токена.
Тема аутентификации очень обширна и технически нетривиальна. Но часто в компаниях принят единый стандарт аутентификации, разработкой этого сервиса занимается отдельная команда с активным участием отдела безопасности. Остальным остается только получать и проверять токены:)
Вот с авторизацией проектировщики API работают гораздо чаще.
Авторизация - это проверка, есть ли у пользователя права на выполнение действия.
На поверхности авторизации лежит ролевая модель и доступ к ресурсам по ролям. Пользователи с ролью “сотрудник” не имеют доступа к ресурсу с зарплатами, в отличие от пользователей с ролью “руководитель”. Может быть более сложная логика: пользователи с ролью “продавец” видят только товары со статусом “готово к продаже”.
Есть и менее очевидные правила доступа, которые, бывает, упускают, особенно если API не имеет пользовательского интерфейса и предназначено для других систем.
Например, если вы служба доставки, которая предоставляет API для магазинов. Делать разный API под каждый магазин довольно накладно, тем более что процесс у вас со всеми примерно одинаковый.
Вы предоставляете один интерфейс для всех. Причем магазины и сети магазинов делают на своей стороне интерфейс для продавцов. То есть на каждого вашего партнера-организации приходится какое-то количество пользователей.
Скорее всего, у вас будет метод получения заказа по UUID/GUID. И критически важно не давать пользователю из одного магазина получать заказы другого магазина. Просто представьте, что будет, если через ваш API ВкусВилл сможет получать заказы для X5.
То есть нам нужно не только понимать подлинность токена пользователя, но и то, что пользователь работает именно в той организации, которой принадлежит заказ. Для этого нужно произвести ряд логических операций и, возможно, вызовов к другим сервисам: получить организацию заказа, получить организацию, в которой зарегистрирован пользователь, сравнить их, обработать ошибку.
Кто-то вам может сказать: зачем заморачиваться, у нас же заказы не инкрементом пронумерованы, а UUID/GUID - их очень сложно подобрать. Но их же можно и не перебором вычислять, а, например, перехватить какие-то вызовы и разжиться нужным списком идентификаторов. Конечно, случайно это сделать не получится, но компании могут на многое пойти, чтобы узнать о продажах своих конкурентов.
В итоге, очень важно внимательно и скрупулезно обдумывать политику доступов к API. Причем не только на уровне доступов к методам и ролевой модели, но и на уровне логики приложения.
ДОСТУП К ДАННЫМ В API
Чтобы подобраться к данным из API клиент, как правило, проходит два этапа: аутентификация и авторизация.
Аутентификация - это проверка подлинности пользователя (правильный логин и пароль, например). Очень часто клиент проходит аутентификацию и получает JWT-токен, с которым делает запросы к API разных сервисов. Сервисы проверяют подлинность и актуальность этого токена при каждом запросе. У токена задается время жизни, по прошествии которого токен надо обновить. Если токен неверный или “протух”, API ответит на вызов ошибкой.
Примечательно, что даже сервис, который сам не генерировал JWT-токен, имея соответсвующий ключ, может проверить подлинность и актуальность токена. Что делает эту технологию очень удобной в случае сервисно-ориентированной и микросервисной архитектуры: достаточно сделать один сервис аутентификации, который будет хранить данные клиентов, выдавать токены и заботиться о безопасности, а остальные сервисы будут иметь дело только с токенами.
Также в JWT-токене может быть какой-то payload, то есть “полезная нагрузка”: данные, которые можно передавать прямо в токене, сообщая что-то сервису. Например, там может быть id пользователя, его роль и доступы и пр. В интересах безопасности payload можно зашифровать. Но, например, в системах, работающих в контуре компании под VPN какие-то данные можно передавать открыто и тогда их легко получить сразу из токена.
Тема аутентификации очень обширна и технически нетривиальна. Но часто в компаниях принят единый стандарт аутентификации, разработкой этого сервиса занимается отдельная команда с активным участием отдела безопасности. Остальным остается только получать и проверять токены:)
Вот с авторизацией проектировщики API работают гораздо чаще.
Авторизация - это проверка, есть ли у пользователя права на выполнение действия.
На поверхности авторизации лежит ролевая модель и доступ к ресурсам по ролям. Пользователи с ролью “сотрудник” не имеют доступа к ресурсу с зарплатами, в отличие от пользователей с ролью “руководитель”. Может быть более сложная логика: пользователи с ролью “продавец” видят только товары со статусом “готово к продаже”.
Есть и менее очевидные правила доступа, которые, бывает, упускают, особенно если API не имеет пользовательского интерфейса и предназначено для других систем.
Например, если вы служба доставки, которая предоставляет API для магазинов. Делать разный API под каждый магазин довольно накладно, тем более что процесс у вас со всеми примерно одинаковый.
Вы предоставляете один интерфейс для всех. Причем магазины и сети магазинов делают на своей стороне интерфейс для продавцов. То есть на каждого вашего партнера-организации приходится какое-то количество пользователей.
Скорее всего, у вас будет метод получения заказа по UUID/GUID. И критически важно не давать пользователю из одного магазина получать заказы другого магазина. Просто представьте, что будет, если через ваш API ВкусВилл сможет получать заказы для X5.
То есть нам нужно не только понимать подлинность токена пользователя, но и то, что пользователь работает именно в той организации, которой принадлежит заказ. Для этого нужно произвести ряд логических операций и, возможно, вызовов к другим сервисам: получить организацию заказа, получить организацию, в которой зарегистрирован пользователь, сравнить их, обработать ошибку.
Кто-то вам может сказать: зачем заморачиваться, у нас же заказы не инкрементом пронумерованы, а UUID/GUID - их очень сложно подобрать. Но их же можно и не перебором вычислять, а, например, перехватить какие-то вызовы и разжиться нужным списком идентификаторов. Конечно, случайно это сделать не получится, но компании могут на многое пойти, чтобы узнать о продажах своих конкурентов.
В итоге, очень важно внимательно и скрупулезно обдумывать политику доступов к API. Причем не только на уровне доступов к методам и ролевой модели, но и на уровне логики приложения.