Как защитить веб-службы RESTful?

Мне нужно реализовать безопасные веб-службы RESTful . Я уже провел небольшое исследование с помощью Google, но я застрял.

Параметры:

TLS (HTTPS) +

• HTTP Basic (pc1oad1etter)
• Дайджест HTTP
• двухсторонний OAuth
• подход на основе файлов cookie
• клиентские сертификаты (Том Риттер и здесь )
• Подписанные запросы с использованием HMAC и ограниченное время жизни

Можно ли рассмотреть другие возможные варианты? Если OAuth, то какая версия? Это вообще имеет значение? Из того, что я читал до сих пор, OAuth 2.0 с токенами-носителями (то есть без подписей) кажется небезопасным .

Я нашел еще одну очень интересную статью об аутентификации на основе REST .

Защитите свой REST API ... правильный путь

Есть еще один, очень безопасный метод. Это клиентские сертификаты. Знаете, как серверы представляют сертификат SSL, когда вы связываетесь с ними по https? Серверы могут запросить сертификат у клиента, чтобы они знали, что клиент - это то, кем они себя называют. Клиенты генерируют сертификаты и передают их вам по безопасному каналу (например, заходя в ваш офис с USB-ключом - предпочтительно USB-ключом без троянской программы).

Вы загружаете открытый ключ сертификатов клиентов сертификатов (и, при необходимости, сертификаты их подписывающих лиц) на свой веб-сервер, и веб-сервер не будет принимать соединения от кого-либо, кроме людей, у которых есть соответствующие закрытые ключи для сертификатов. он знает о. Он работает на уровне HTTPS, поэтому вы даже можете полностью пропустить аутентификацию на уровне приложения, такую ​​как OAuth (в зависимости от ваших требований). Вы можете абстрагироваться от слоя и создать локальный центр сертификации и подписывать запросы сертификатов от клиентов, что позволяет пропустить этапы «заставить их приходить в офис» и «загрузить сертификаты на сервер».

Боль в шее? Абсолютно. Подходит для всего? Неа. Очень безопасно? Ага.

Однако он полагается на то, что клиенты сохраняют свои сертификаты в безопасности (они не могут размещать свои закрытые ключи в Интернете), и обычно используется, когда вы продаете услугу клиентам, а не позволяете кому-либо зарегистрироваться и подключиться.

В любом случае, это может быть не то решение, которое вы ищете (вероятно, не по правде), но это другой вариант.

HTTP Basic + HTTPS - один из распространенных методов.

Если вы выбираете между версиями OAuth, используйте OAuth 2.0.

Токены носителя OAuth следует использовать только с безопасным транспортом.

Токены носителя OAuth настолько же безопасны или небезопасны, как транспорт, который шифрует диалог. HTTPS обеспечивает защиту от атак повторного воспроизведения, поэтому токену-носителю не обязательно также защищать от повторного воспроизведения.

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

Если вам нужно защитить полезные данные, которые проходят через нескольких участников, вам нужно нечто большее, чем HTTPS / SSL, поскольку HTTPS / SSL шифрует только одну ссылку на графике. Это не ошибка OAuth.

Токены-носители легко получить для клиентов, их легко использовать для вызовов API, и они широко используются (с HTTPS) для защиты общедоступных API-интерфейсов из Google, Facebook и многих других служб.