Как безопасно обращаться с потребительским ключом и секретом при использовании WSO2 в качестве шлюза API для мобильного приложения

Мы создаем мобильное приложение и его API-сервер с архитектурой, как на картинке ниже.

введите здесь описание изображения

У нас есть WSO2 в качестве шлюза API перед сервером API Spring Boot. Мы используем WSO2 API Manager, чтобы ограничить круг лиц, которые могут вызывать API. Только клиенты, которые зарегистрировались в нашем WSO2 и имеют правильный ключ и секрет потребителя, могут вызывать API через WSO2, с помощью которого клиент сначала обращается к конечной точке токена WSO2 для обмена ключом и секретом потребителя с токеном доступа, а затем вызывает желаемый API. с токеном доступа в заголовке Authorization: Bearer <access token>

У нас есть проблема, заключающаяся в том, что мы не знаем, как сохранить секрет потребителя, поскольку проверки безопасности запрещают нам хранить секрет в пакете установщика мобильного приложения.

Были уже заданы некоторые вопросы, такие как

WSO2 API Manager - Как мобильное приложение подключается к диспетчеру API?

Безопасность WSO2 Api Manager OAuth2 DCR в общедоступном собственном мобильном устройстве приложение

Но ни один ответ правильно не указывает на проблему. Большинство из них были введены в заблуждение сложностью потока oauth2.

Чтобы сделать проблему конкретной и ясной, предположим, что на нашем мобильном телефоне нет пользователей для входа в систему. Цель этой проблемы — разрешить только доверенным мобильным приложениям вызывать API через WSO2.

Помогите, подскажите, возможно это или нет. Или у нас нет другого выбора, кроме как позволить любому вызывать API. Или функция потребительской подписки WSO2 вообще не предназначена для использования непосредственно из мобильного приложения?


ios android api-gateway oauth-2.0 wso2
person asinkxcoswt    schedule 25.12.2019    source источник
comment
Короткий ответ: вы не можете. Вы можете запутать токены/ключи, чтобы усложнить задачу злоумышленнику, но, по сути, вы не можете доверять устройству, поскольку физически не контролируете его.   -  person Paulw11    schedule 25.12.2019

Ответы (2)


arrow_upward
1
arrow_downward

Проведя некоторое исследование, я обнаружил 2 варианта, которые обычно делают люди.

  1. Разделите API на 2 группы. Первая группа содержит API, которые необходимо использовать без входа пользователя в систему, например, API для получения данных инициализации или для получения данных для целевой страницы приложения. Эти API-интерфейсы установлены как общедоступные, что позволяет любому звонить без идентификатора клиента и секрета. Группа секунд содержит защищенные API, которым требуется токен. Мобильное приложение может использовать поток Oauth2 PKCE для обмена токеном с подтверждением личности пользователя.

  2. Замаскируйте clientId и секрет и сохраните их в пакете установщика мобильного приложения. API по-прежнему разделены на 2 группы, как и раньше. Но для первой группы требуется токен уровня клиента (тип учетных данных клиента oauth2), а для второй группы требуется токен уровня пользователя (пароль владельца ресурса или тип кода авторизации).

Я предпочитаю вариант 2. На мой взгляд, первый вариант не имеет особого смысла. Люди, выбирающие этот вариант, возможно, просто делают это, чтобы обойти контрольный список аудита безопасности, to not store the secret in public client, не особо беспокоясь о проблеме безопасности. Это как когда ты не можешь доверить своим детям ключи от твоего дома, поэтому ты решил снять замок с двери.

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

person asinkxcoswt    schedule 29.12.2019

arrow_upward
0
arrow_downward

Вы можете прочитать спецификацию OAuth 2.0 для нативных приложений [RFC7636]. Говорится:

Клиенты общедоступных собственных приложений ДОЛЖНЫ реализовывать расширение Proof Key for Code Exchange (PKCE [RFC7636]) для OAuth, а серверы авторизации ДОЛЖНЫ поддерживать PKCE для таких клиентов по причинам, подробно описанным в Разделе 8.1.

Проверьте также ответ ниже.

Как реализовать Oauth2 без отправки client_secret в WSO2 APIM

person Bee    schedule 25.12.2019
comment
Спасибо, но PKCE требует входа пользователя в обмен на токен. - person asinkxcoswt; 29.12.2019