Безопасность для "Private" REST API

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

Я много читал о том, как OAuth является идеальным механизмом защиты API, и на этом этапе я начинаю хорошо понимать, как это работает.

Мой вопрос - так как я никогда не предоставляю доступ к моему API стороннему клиенту, действительно ли нужен OAuth? Есть ли причина, по которой это выгодно? Кроме того, поскольку задний конец - это просто API, для аутентификации пользователя нет шлюза (например, если вы пишете приложение с использованием API Twitter, когда пользователь аутентифицируется, они будут направлены на страницу Twitter, чтобы предоставить доступ затем перенаправляется обратно клиенту).

Я не уверен, в каком направлении идти. Кажется, должен быть какой-то подход на полпути между HTTP-аутентификацией и OAuth, что было бы подходящим для этой ситуации, но я просто не понимаю.

Ответ 1

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

Что такое ненадежный клиент? Подумайте о том, кто обрабатывает учетные данные, которые предоставляют доступ к вашему API.

Например, ваше веб-приложение может взаимодействовать с вашим API в двух falvors:
- Ваша сторона сервера веб-приложений ведет переговоры с вашим API. Ваш сервер веб-приложений является доверенным клиентом, поскольку учетные данные для доступа к вашему API могут быть только доступом, у которого есть доступ к серверу... Вы и ваша команда. Вы можете аутентифицировать сервер веб-приложений с помощью client_id и client_secret.
- Вы можете совершать вызовы непосредственно в свой API от своего клиента веб-приложения, который работает в браузере конечного пользователя с использованием JavaScript. Браузер конечного пользователя является ненадежным клиентом. Если вы должны доставить учетные данные для вашего API до браузера, каждый может проверить код JavaScript и украсть ваши учетные данные.
Стороннее приложение для сторонних разработчиков также не доверено. Злоумышленник, который использует ваш API, может сохранить учетные данные и конечный пользователь вашей платформы.
Ваше собственное приложение является надежным клиентом и может управлять аутентификацией простым именем пользователя, паролем и идентификатором клиента, идентифицирующим ваше приложение.

Как помочь OAuth? OAuth Код авторизации и Неявные могут помочь вам в решении этой проблемы. Эти потоки работают только с клиентами, которые поддерживают перенаправление, например, в браузере. И позвольте вам аутентифицировать ненадежного клиента и пользователя на вашем сервере авторизации, чтобы получить доступ к вашему серверу ресурсов, вашему API, не подвергая учетные данные. Взгляните на RFC, чтобы узнать, как это делается.

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

Ответ 2

OAuth 2.0 изначально кажется PITA, если вы думаете о том, что нужно много строить самостоятельно, но на большинстве языков есть некоторые действительно прочные установки OAuth 2.0, которые вы можете просто вставлять с разным количеством возиться. Если вы используете фреймворк вроде Laravel или RoR, то это едва ли работает.

PHP: http://oauth2.thephpleague.com/
Ruby (Rails или Grape): https://github.com/doorkeeper-gem/doorkeeper

Если вы не хотите перенаправлять пользователей, как было предложено в вашем сообщении, то игнорируйте другие комментарии и ответы, в которых говорится о двух ночных потоках. Вы можете использовать тип гранта client_credentials, чтобы приложения просто предоставляли свой идентификатор клиента и секрет в обмен на токен доступа, что приятно и легко.

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

Но если это личное в смысле "наше приложение для iPhone использует его", то вы определенно хотите пойти с OAuth 2.0 или что-то в этом роде.

Ответ 3

2 legged OAuth - это, вероятно, то, что вы хотите использовать. Это в основном хэширование общего ключа, но у вас есть преимущество в том, что вам не нужно писать код самостоятельно.

Вот связанный с этим вопрос: Двусторонний OAuth - поиск информации

Ответ 4

Вы должны использовать Oauth для обмена мобильным устройством с интерфейсом уровня API.

Тем не менее, нет пользы Oauth в этом веб-интерфейсе для доступа к среднему уровню (машина для машины).

С другой стороны, существуют некоторые потенциальные проблемы

Управление истечением токена доступа становится болью. Подумайте, что ваш пользовательский интерфейс должен кэшировать токен доступа на нескольких узлах кластера. Обновите его, когда истек, и тот факт, что уровень пользовательского интерфейса согласовывает безопасность с бэкэнд, будет занимать дополнительное время раз в то время.
В двухногих Oauth (учетные данные OAuth Client, как и в версии 2.0) не поддерживает шифрование. Поэтому вам по-прежнему нужно отправлять ключ и секрет как на сервер для получения токена доступа.
Backend должен реализовать выпуск токена доступа, обновить токен, проверить токен доступа и т.д. без каких-либо существенных преимуществ