Безопасный доступ к данным в RESTful API

Question

Я полагал, что на этот вопрос уже отвечали ранее, но быстрый ТАК поиск ничего не дал.

У меня есть частный API, который заблокирован APIKey. Этот ключ необходимо передавать для каждого запроса. С помощью этого ключа вы можете получить доступ к любой части API. Очевидно, это довольно открыто . По большей части это приемлемо. Однако в некоторых случаях я хочу убедиться, что запрос отправлен владельцем данных.

Например, рассмотрим запрос update или delete . Вы не должны быть в состоянии сделать этот запрос для чужих данных. Таким образом, в дополнение к APIKey, я хотел бы иметь что-то еще, чтобы этот пользователь, выполняющий запрос, был авторизован для выполнения этого действия.

Я мог бы потребовать, чтобы ownerID был передан с таким запросом. Но это быстро подделано. Итак, что я получил.

Мне интересно услышать, что другие члены SO реализовали в этих ситуациях. Индивидуальные APIKeys? Двойная авторизация

Если это имеет значение, мой API следует архитектуре REST и разработан с использованием PHP / Apache.

Answer 1

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

Когда приходит запрос, сопоставьте ключ API спользователь, а затем определить, является ли этот пользователь «владельцем» ресурса, с которым он пытается взаимодействовать.

Вся часть «определения владельца» - это отдельная проблема, которую сложно сделать в API в зависимости от того, насколько хорошо система была построена.Я могу поделиться тем, как мы это делали в прошлом, но решил, что это немного не по теме.

Answer 2

Предложите вам рассмотреть возможность использования Oauth.Подводя итог, вот как это должно работать.

Каждому приложению, выполняющему вызовы API, потребуется соответствующий API-ключ уровня приложения для авторизации через процесс Oauth.Apikey здесь будет просто представлять идентификатор приложения (клиента).

Каждый конечный пользователь, связанный с использованием, должен аутентифицировать себя отдельно (независимо от apikey) в процессе авторизации Oauth.Идентификация пользователя, связанный контекст, такой как область авторизации, затем кодируется в токен, называемый токеном доступа.

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

На стороне реализации API проверка маркера доступа должна раскрывать контекст конечного пользователя (включая объем доступа, который предоставляется во время процесса Oauth), и, следовательно, доступ / авторизация для использования конкретного ресурса могут бытьуправляется сервером ресурсов.

Answer 3

Ключи API должны быть уникальными для каждого пользователя.Это проверит пользователя и что он должен иметь доступ к данным.

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

SSL для всех запросовтакже предлагается.