Лучший способ защитить частный REST API без аутентификации пользователя для мобильного приложения

Я делаю несколько полезных API для моего мобильного приложения.

Связь между APP и веб-сервером должна выполняться в REST. Эти apis должны быть закрытыми, и только мое приложение должно иметь возможность называть их успешными результатами.

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

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

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

Ответ 1

Взгляните на механизм кода аутентификации сообщения Hash (Hash).

Ссылка в Википедии: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code

Вашему клиенту (мобильному приложению) потребуется ключ public API, который идентифицирует клиента веб-службы REST и закрытый/ криптографический ключ. Открытый API API можно отправить вместе с HTTP-запросом. Это публично, и все это видят. Частный ключ, однако, никогда не должен отправляться вместе с запросом и должен быть известен только серверу и клиенту. Этот ключ используется для генерации хэшированного сообщения, которое вместо этого будет отправлено на сервер. HMAC может быть сгенерирован с использованием алгоритма SHA1/MD5, сообщения, которое должно генерироваться алгоритмом, который знает как сервер, так и клиент, и, наконец, закрытый ключ.

Ответ 2

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

клиент (ваше приложение) вызовет требуемый API
сервер отклонит его, но в ответ он отправит строку, содержащую случайный хеш (= вызов).
клиент использует эту строку в сочетании с некоторой другой строкой (= пароль) (уже встроенной в приложение) для генерации нового хэша (= дайджест)
клиент снова вызовет тот же API, но на этот раз использует вновь созданный дайджест в качестве параметров аутентификации.
сервер проверит этот дайджест и продолжит

FYI: вышеупомянутая процедура является общепринятым стандартом и называется Digest Authentication. Если вам нужна дополнительная помощь, просто попросите Google "проверить подлинность электронной почты Android"

Ответ 3

Я бы предложил создать сложный токен в приложении, сделанный из timestamp + appId + любое другое значение, которое вы можете реплицировать на сервере, и аутентифицировать в заголовке каждого запроса, используя эти.

Например, вы можете создать виртуального "пользователя" в своем db и сохранить в нем deviceToken и использовать его для своего алгоритма.

Я лично сохраняю один запрос API public, который является метрической меткой времени, которая возвращает метку времени сервера для использования в течение 300 секунд.

поэтому перед каждым запросом получите временную метку и отправьте созданный токен, скопируйте его на сервере и, таким образом, подтвердите запрос.

Захватывающий хакер может перепроектировать приложение и воспроизвести ваши жетоны, хотя