Каково нынешнее состояние мудрости для защиты REST API?

Question

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

1. Существует OAuth 1.0, но, как утверждается, он более сложный, чем он должен быть, и не слишком хорошо поддерживает родные клиенты (обратные URL-адреса очень ориентированы на браузер). С другой стороны, есть один крупный поставщик, который его поддерживает (Twitter).
2. Тогда есть OAuth 2.0, который должен быть улучшен более чем на 1.0, и он избавляется от криптографии на стороне клиента в нем по умолчанию (заменяется токенами-носителями), но некоторые люди считают, что it's broken by design и bearer tokens are no better than cookies. SSL-сертификат от отрывочного провайдера легче обмануть мобильного клиента, полагая, что конечная точка является доверенным органом. Однако два основных поставщика (Google и Facebook) поддерживают его.
3. И есть люди, которые advocate sidestepping the whole mess and rolling your own.

Так что это?

Answer 1

Это будет звучать как хеджирование, но ответ «все, что подходит для вашего приложения».

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

Однако вы можете создать систему, которая не имеет этого ограничения или требования, и может быть разумным попросить ваших клиентов просто создать учетную запись на вашем сервере. В этом случае вы, возможно, можете значительно упростить ситуацию, используя HTTPS и Basic Auth. Попросите клиента передать свое имя пользователя/пароль в соответствующем заголовке и убедиться, что ваше соединение защищено SSL. Или попросите клиента использовать сертификат для своих учетных данных.

Я предлагаю вам начать с перечисления того, что означает «безопасность», и работать с нуля. Рассмотрите все связанные аспекты, такие как гарантии целостности, неотрицательность, защита воспроизведения, влияние клиента, производительность и удобство использования API. Оттуда выясните, нужно ли всего вам HTTPS/basic auth, или вам также нужно добавить ключи API, OAuth, OpenID, контрольные суммы и т. Д.

Answer 2

Я бы рекомендовал OAuth 2, но с дополнительными проверками сертификата в клиентов. Если ваш сертификат поступает из Verisign, то недействительны все сертификаты от других ЦС. Убедитесь, что вы всегда получаете свои сертификаты в одном и том же ЦС, хотя, если вам не нравится распространять обновления.

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