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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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