Как сделать REST безопасно и с конфиденциальными данными?

Question

мы внедряем новый веб-сервис. Веб-сервис будет хранилищем конфиденциальных данных, и существует несколько типов пользователей с разными разрешениями. Поэтому некоторые типы пользователей не могут получить доступ (а некоторые не могут изменить и т. Д.) К определенным типам данных. Как это будет работать в REST? Я очень новичок в REST, так что извините, если это звучит нубистски.

Answer 1

Ваш первый шаг - предоставить некоторое транспортное шифрование в форме SSL. Это должно позаботиться о том, чтобы никто не находился в середине атаки, и чтобы никто не отслеживал данные. Во-вторых, вам нужно выяснить какой-то метод аутентификации. Популярным методом является создание службы входа в систему, которой вы отправляете имя пользователя и пароль, и она возвращает своего рода ограниченный жизненный ключ. Затем вы отправляете этот ключ вместе со всеми последующими запросами, и сервер проверяет его перед возвратом каких-либо данных. Если у вас разные уровни пользователя, то, кроме проверки ключа, также проверьте, должен ли данный пользователь иметь доступ к этой информации.

Answer 2

Как гласит первый автор, это популярная модель, позволяющая клиентам сначала пройти аутентификацию в вашей системе (Google делает это для ряда своих API). Ответ на который включает токен, который клиент должен включить в качестве параметра при последующих запросах.

например. HTTP POST (через SSL) до http://you/auth с именем пользователя и (MD5 хэш пароля) - сравните это с MD5 пароля, который вы сохранили для них.

Ответьте HTTP 200 OK, а тело сообщения или заголовок - токеном аутентификации.

Это дает двоякое преимущество по сравнению с повторной отправкой аутентификационных учетных данных при каждом запросе. Кроме того, снижаются накладные расходы на обработку токена (теперь это просто проверка достоверности - возможно, в хранилище действительных токенов в памяти), а не поиск в БД пользователя и пароля. Вы также уменьшаете количество раз, когда учетные данные отправляются по сети (хотя и шифруются благодаря SSL).

Внедрение контроля доступа на конечных точках ресурсов потребует немного больше работы, но в основном это просто определение того, какие токены могут использоваться с какими ресурсами. Это будет зависеть от вашего сценария.

Надеюсь, что это имеет смысл, и удачи.

Answer 3

Независимо от того, что вы, вероятно, захотите зашифровать с помощью HTTPS.

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

Либо у вас может быть запрос на вход, который аутентифицирует пользователя и возвращает маркер состояния сеанса в файле cookie или как часть ответа.