Я довольно новичок в API REST, и я понимаю, что есть уже несколько вопросов, уже опубликованных. Тем не менее, пересмотр этих вопросов фактически оставил меня более смущенным тем, как с этим справиться.
Я создал REST API, используя Slim Framework, который я просто использую для передачи данных. Я не буду использовать логины пользователей или аутентификацию, поэтому я считаю, что для этого мне нужна система, которая использует открытый ключ и закрытый ключ, но я просто не уверен.
Если у кого-то есть представление о правильном / наиболее безопасном способе сделать это, или о любых учебниках / ресурсах, которые были бы замечательными. Любая помощь приветствуется.
Вы можете использовать SSL для шифрования данных в пути.
Но SSL – это просто шифрование; сервер ssl не выполняет аутентификацию клиента, а также авторизацию. Вы можете думать о авторизации, поскольку ответ на вопрос : позвонивший разрешает делать то, что он спрашивает? , Аутентификация, устанавливающая идентификатор вызывающего или аутентификация, обычно является необходимым первым шагом для авторизации. Иногда вам не нужна «вся идентичность» – вам просто нужно выяснить конкретный аспект. Например, автоматические ворота для туалетных комнат не должны были знать, кто вы, но только если вы были мужчиной или женщиной, чтобы установить личность. Точно так же некоторые службы не заботятся о том, кто вы; они разрешат доступ, если вы звоните из определенной сети (белый список ip), или если у вас есть специальный токен.
Чтобы сервер мог различать разрешенные и неавторизованные вызовы, у вас есть несколько вариантов:
Белый список IP. Если вы знаете IP-адрес приложения или агента, который будет вызывать вашу службу, вы можете указать это в своей реализации службы. Служба может проверять IP-адрес входящих запросов и отклонять те, которые не включены в белый список. Это своего рода «неявное» разрешение, основанное на адресе вызывающего абонента.
секретный токен, который приложение предоставляет в каждом вызове. Вы сказали, что не хотите выполнять аутентификацию, но это форма проверки подлинности. Вы можете назвать это «токен-носитель». Любой, кто несет этот токен, получает авторизацию. На вашем сервере вы должны проверить значение токена и отклонить любые вызовы, которые не соответствуют известному значению. Это очень похоже на белый список IP, за исключением того, что токен явно передан и не имеет никакого отношения к сетевому адресу.
пару токенов + ключ. Это похоже на имя пользователя / пароль, но его можно использовать для аутентификации приложения. Используйте это, чтобы обеспечить идентичность самого приложения. Проверьте на стороне обслуживания, как указано выше.
имя пользователя / пароль. Чтобы выполнить аутентификацию пользователя приложения.
Вы можете объединить их для создания необходимого вам решения. Другими словами, запрос клиента должен быть от правого адреса, и для него должен быть токен / ключ для приложения, а также имя пользователя / пароль для пользователя, чтобы считаться «авторизованным».