Двойная аутентификация для RESTful API

Question

В настоящее время я создаю RESTful API для нашего веб-сервиса, к которому будут обращаться сторонние веб-приложения и мобильные приложения. Мы хотим иметь определенный уровень контроля над потребителями API (т. Е. Веб-приложениями и мобильными приложениями), чтобы мы могли регулировать запросы API и / или блокировать определенные вредоносные клиенты. Для этого мы хотим, чтобы каждый разработчик, который будет обращаться к нашему API, получал от нас ключ API и использовал его для доступа к нашим конечным точкам API. Для некоторых вызовов API, которые не имеют отношения к конкретной пользовательской информации, это единственный требуемый уровень аутентификации и авторизации, который я называю A & A уровня приложения. Однако некоторые вызовы API имеют дело с информацией, принадлежащей конкретным пользователям, поэтому нам нужен способ, позволяющий этим пользователям войти в систему и авторизовать приложение для доступа к их данным, что создает второй уровень (или пользовательский уровень A & A).

Имеет смысл использовать OAuth2 для пользовательского уровня A & A, и я думаю, что у меня есть достаточно хорошее понимание того, что мне нужно здесь делать.

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

Теперь у меня проблема в том, как соединить эти два разных механизма. Моя текущая гипотеза состоит в том, что я продолжаю использовать API ключ / секретная пара для подписания всех запросов, чтобы иметь возможность доступа ко всем конечным точкам API, и для тех вызовов, которые требуют доступа к пользовательской информации, приложения должны будут пройти через поток OAuth2 и получить токены доступа. и снабди их.

Итак, мой вопрос к сообществу: звучит ли это как хорошее решение, или есть несколько лучших способов это спроектировать.

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

Answer 1

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

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

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

При работе с чисто вредоносными клиентами мы выпускаем адвокатов (в нашем случае злонамеренное использование почти всегда является нарушениемруководящие принципы вики);технические решения не достаточно сложны в нашей оценке.Обратите внимание, что число вредоносных клиентов действительно очень низкое (однозначные цифры за годы работы с миллионами ежедневных запросов API).IP и на основе пользователя.