Является ли OAuth хорошим выбором для API RESTful в этом сценарии SaaS?
Является ли OAuth разумным использовать, когда информация учетной записи пользователя (идентификаторы пользователя, пароли, роли и т.д.) будут поддерживаться в нашем собственном back-end и когда не будет совместного использования ресурсов с другими сайтами? Или разделяет всю точку использования OAuth?
Фон:
Я работаю над разработкой продукта SaaS предприятия, и мы создаем RESTful API, который будет использоваться нашими внешними приложениями. Потребителями API будут приложения для браузера и родного смартфона (iOS и Android), которые мы разрабатываем. Поскольку мы будем поддерживать несколько типов клиентов, имеет смысл создать RESTful API, который могут использовать все наши клиентские приложения.
Естественно, нам нужно обеспечить этот RESTful API. Мы рассматриваем аутентификацию с использованием HTTPS/Basic Auth, но нам известны некоторые из известных недостатков этого подхода.
Некоторые быстрые исследования показывают, что OAuth настоятельно рекомендуется. Но большинство из того, что я нахожу в OAuth, в контексте авторизации веб-сайтов для обмена информацией от имени пользователя.
Любая информация, если вам больше всего нравится.
Ответы
Ответ 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, вам будет легче сделать этот переход позже.
Ответ 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
Ответ 3
Я внедрил OAuth для Django нереле с поршнем, чтобы разоблачить мои API для потребителя. Есть несколько видов в OAuth (2-ноги 3legs).
Как правило, поддержка OAuth - довольно сложная задача. Вы должны получить токен запроса, разрешить его, хранить токен доступа, чтобы подписывать каждый запрос, который вы хотите аутентифицировать.
Преимущества
- Вам не нужно отправлять имя пользователя и пароль каждый раз, безопасно.
- Включить стороннее использование вашего приложения.
Недостатки
- Сделайте 2,3 раунда поездки для аутентификации.
- Сложно реализовать его самостоятельно.
Я уверен, что вы можете найти несколько библиотек, которые позволят вам:
- Откройте свой Api и поддержите OAuth. Например, поршень Django.
- Подпишите свои запросы, добавив к ним заголовки. Например, Oauth-указатель.
Ответ 4
OAuth - это только токен, и запрашивающее приложение выдает его. Вы можете прочитать больше на pingidentity.com, где есть несколько веб-семинаров по этой теме (облачная идентификация и пользовательское обеспечение).
