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

Question

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

Это имеет смысл использовать OAuth2 для «user» -level A & A, и я думаю, что у меня довольно хорошее понимание того, что мне нужно делать здесь.

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

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

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

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

Answer 1

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

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

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

Имея дело с чисто вредоносными клиентами, мы развязываем юристов (вредоносное в нашем случае почти всегда является нарушением рекомендаций cc-wiki); технические решения не достаточно сложны в нашей оценке. Обратите внимание, что количество вредоносных клиентов действительно очень низкое (однозначные числа за годы работы, с миллионами ежедневных запросов API).

Короче говоря, я бы выбрал OAuth 1.0 и переключил ваши дроссели на гибрид IP и на основе пользователей.