Как обезопасить конечную точку API PHP JSON, взаимодействующую с приложением android?

Question

Если приложение взаимодействует с API-интерфейсом сервера по протоколу https с помощью метода post (JSON объекты), существует опасность, что конечная точка API-интерфейса будет раскрыта и кто-либо получит доступ к API-интерфейсу. Есть ли способ убедиться, что api называется только из назначенного приложения.

Я провел небольшое исследование в сети и узнал:

a. ручная проверка учетных данных методом POST

b. используя json веб-токены (jwt)

Однако мой вопрос: оба эти метода a) и b) потребовали бы передачи какого-либо имени пользователя / пароля через клиентское приложение на сервер (каждый раз в. и только один раз в б.) Теперь это имя пользователя / passwd должно быть жестко закодировано в apk, и его можно легко получить, декомпилировав его. Итак, насколько эти методы безопасны?

Answer 1

Я бы как-то использовал безопасность TLS ... с цифровыми сертификатами ... для криптографической защиты сетевого доступа к порталу. Приложение будет содержать необходимый опубликованный сертификат c, возможно, запутанный, который сервер может проверить, чтобы убедиться, что доступ является законным. Теперь никто не может перехватить сообщения, и они не могут подделать его, не извлекая сначала информацию о сертификате из приложения, что, вероятно, маловероятно. Знание, что соискатель обладает копией необходимого ключа publi c, должно быть достаточной аутентификацией.

Хотя мы обычно не используем его, когда используем TLS, чтобы добраться до вашего дружеского соседства https web- site, такие модули, как mod_ssl do , обеспечивают полную реализацию TLS, включая возможность требовать и проверять клиентский сертификат безопасности, без обладания которого попытка подключения будет отклонена , Это может быть идеальная ситуация для этого.

Answer 2

Я думаю, вы не понимаете, как работают json веб-токены или токены на предъявителя. Почему имя пользователя и пароль должны быть жестко закодированы? Вы бы предоставили пользователю интерфейс, который принимает имя пользователя и пароль.

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

Если используется токен, пользователь все равно вводит свое имя пользователя и пароль для аутентификации, сервер возвращает действительный токен авторизации. С этого момента токен аутентификации передается с каждым запросом.