Защита REST API и Slim Framework

Навигация
17

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

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

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

    
задан Drew 30.10.2012 в 14:01
источник
  • Проницательность на самом безопасном пути ... что делать? Что вы пытаетесь достичь? Вы хотите «обеспечить его». Что это значит? Какова цель? Вы хотите разрешить доступ только к доверенным пользователям? Вы хотите шифровать данные в пути? Вы хотите разрешить только одно использование для каждого клиента? и т. д. Вы сказали, что хотите «защитить это», но не хотите использовать аутентификацию. Тогда вам нужно быть более конкретным, что означает «обеспечить это». –  Cheeso 30.10.2012 в 19:39
  • API будет вызываться с разных сайтов, но пользователь не будет знать, что он есть, поскольку он просто используется для извлечения данных на бэкэнд. Моя цель - безопасно называть этот api из кода, а также шифровать данные. –  Drew 30.10.2012 в 20:01

1 ответ

15

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

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

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

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

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

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

  • имя пользователя / пароль. Чтобы выполнить аутентификацию пользователя приложения.

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

ответ дан Cheeso 30.10.2012 в 20:33
  • Спасибо Cheeso за отличный ответ. Для меня потребуется некоторое время, чтобы реализовать все это, но это определенно отправило меня на путь. –  Drew 01.11.2012 в 13:25
  • @ Чисо, приятное резюме. У вас есть примеры реализации, идеи для начала с собственной реализацией, учитывая, что запущен и запущен базовый API REST ... –  Matt Bannert 13.10.2015 в 18:53

Генерировать документацию как файлы разметки с использованием doxygen [закрыто]

Как использовать псевдонимы с MySQL LEFT JOIN