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

Question

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

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

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

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

Answer 1

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

Вот связанный с этим вопрос: Two-legged OAuth - looking for information

Answer 2

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

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

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

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

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

3. Backend должен осуществлять выдачу маркера доступа, обновить маркер, проверку маркера доступа и т.д., без какой-либо существенной выгоды

Answer 3

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

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

• Например, веб-приложение может взаимодействовать с API в двух falvors:

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

• Стороннее приложение для сторонних разработчиков также не доверено. Злонамеренный разработчик, который использует ваш API, может сохранить учетные данные и конечный пользователь вашей платформы.

• Ваше собственное приложение является доверенным клиентом и может управлять аутентификацией простым именем пользователя, паролем и идентификатором клиента, идентифицирующим ваше приложение.

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

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

Answer 4

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

• PHP: http://oauth2.thephpleague.com/
• Ruby (Rails или винограда): https://github.com/doorkeeper-gem/doorkeeper

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

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

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