Защита API REST и Slim Framework

Я довольно новичок в REST APIs, и я понимаю, что уже опубликовано довольно много вопросов. Однако, просматривая их, на самом деле оставил меня более смущенным о том, как справиться с этим.

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

Если кто-то имеет представление о правильном / наиболее безопасном способе сделать это, или любые учебники / ресурсы, которые были бы велики. Любая помощь приветствуется.

17
api php rest slim

1 ответов

вы можете использовать SSL для шифрования данных при передаче.

но SSL-это просто шифрование; серверный ssl не выполняет аутентификацию клиента, ни авторизацию. Вы можете думать о авторизация как ответ на вопрос дозволено ли звонящему делать то, что он просит?. проверка подлинности установление личности вызывающего абонента или аутентификации обычно является необходимым первым шагом для авторизации. Иногда тебе не нужно "целое". идентичность " - нужно просто констатировать определенный аспект. Например, автоматизированные ворота туалета не должны знать кто вы были, но только если вы были мужчиной или женщиной, чтобы установить личность. Точно так же некоторые службы не заботятся о том, кто вы; они разрешат доступ, если вы звоните из определенной сети (белый список ip) или если у вас есть специальный токен.

чтобы позволить серверу различать авторизованные и несанкционированные вызовы, которые у вас есть некоторые варианты:

  • белый список IP-адресов. Если вы знаете IP-адрес приложения или агента, который будет вызывать вашу службу, вы можете указать, что в реализации сервиса. Служба может проверить IP входящих запросов и отклонить те, которые не находятся в белом списке. Это своего рода" неявная " авторизация на основе адреса вызывающего абонента.

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

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

  • логин / пароль. Для аутентификации пользователя приложения.

вы можете объединить их, чтобы получить решение, которое вы хотите. Другими словами, запрос клиента должен быть от правого I-адреса и должен иметь токен/ключ для приложения и имя пользователя/пароль для пользователя, чтобы считаться "авторизованным".

15