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

Question

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

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

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

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

Answer 1

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

• PHP: http://oauth2.thephpleague.com/
• Рубин (Рельсы или Виноград): https://github.com/doorkeeper-gem/doorkeeper

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

3. В бэкэнде должна быть реализована выдача токена доступа, обновление токена, проверка токена доступа и т. Д., Без каких-либо существенных преимуществ

Answer 4

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

Вот связанный вопрос: Двуногий OAuth - ищет информацию