Является ли OAuth хорошим выбором для RESTful API в этом сценарии SaaS?

Question

Целесообразно ли использовать OAuth, когда информация об учетной записи пользователя (идентификаторы пользователей, пароли, роли и т. Д.) Будет храниться в нашем собственном бэкэнде и когда не будет никакого обмена ресурсами с другими сайтами? Или разделяет весь смысл использования OAuth?

Справочная информация:

Я работаю над разработкой корпоративного SaaS-продукта, и мы создаем RESTful API, который будет использоваться нашими интерфейсными приложениями. Потребителями API будут браузерные и нативные приложения для смартфонов (iOS и Android), которые мы разрабатываем. Поскольку мы будем поддерживать несколько типов клиентов, имеет смысл создать RESTful API, который могут использовать все наши клиентские приложения.

Естественно, нам нужно защитить этот RESTful API. Мы рассматриваем аутентификацию с использованием HTTPS / Basic Auth, но нам известны некоторые из известных недостатков этого подхода.

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

Любая информация, если приветствуется.

Answer 1

Хороший вопрос, и у нас есть хорошее обсуждение этого вопроса на API Craft:

https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00

Вот ответ, который я разместил там:

Я думаю, что на самом деле это хороший вариант использования OAuth.

Прежде всего, с помощью OAuth ваше мобильное приложение может хранить токен OAuth на клиенте, а не на «реальном» пароле пользователя.Таким образом, вы можете заставить приложение автоматически «входить в систему», получая токен OAuth без необходимости сохранять действительный пароль на устройстве.Если пользователь теряет устройство или если оно каким-либо образом скомпрометировано, они (или вы) могут стереть токен OAuth, не требуя от пользователя смены пароля и удаления других вещей, которые они могут делать с вашим API.Существуют аналогичные примеры для веб-приложения в стиле Ajax, но оно больше зависит от конкретного способа создания клиента.

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

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

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

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

Answer 2

Да, это очень хорошо подходит для OAuth.Вы все еще можете использовать HTTP Basic через SSL во время рукопожатия для аутентификации.Результатом рукопожатия OAuth будет токен, который затем может быть использован для использования API.Таким образом, приложению не нужно хранить учетные данные, и токены могут быть легко отозваны с минимальным влиянием пользователя.

OAuth 2.0 определяет ряд различных типов предоставления для учета различных ситуаций.Мне кажется, что «неявные» или «учетные данные пароля владельца ресурса» являются наиболее подходящими, но вы, возможно, захотите тщательно рассмотреть каждый из них.

Не следует реализовывать это непосредственно в своем API, но используйте инфраструктуру для делегированияподдержка OAuth и управление токенами от имени вашего SaaS API.

Взгляните на

http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/

и

http://www.layer7tech.com/products/oauth-toolkit

Надеюсь, эта помощь,

-fl

Answer 3

Я реализовал OAuth для Django nonrel с поршнем, чтобы предоставить свои API потребителю. Есть несколько видов в OAuth (2 ноги 3 ноги).

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

Преимущества
- Вам не нужно каждый раз отправлять имя пользователя и пароль, secure .
- Разрешить стороннему приложению использовать ваше приложение.
Недостатки
- Для проверки подлинности совершите 2,3 поездки.
- Сложно реализовать это самостоятельно.

Я почти уверен, что вы можете найти несколько библиотек, которые позволят вам:
- Выставь свой Api и поддержи OAuth. Например, поршень Джанго.
- Подпишите ваши запросы, добавив к ним заголовки. Например, указатель.

Answer 4

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