Ограничение скорости API приложения Facebook открыто для злоупотреблений со стороны пользователей access_tokens? - PullRequest
0 голосов
/ 04 августа 2020

Я очень запутался. Я разрабатываю приложение iOS и интегрировал SDK Facebook.

Теперь пользователь может авторизовать мое приложение для доступа к своей учетной записи FB, войдя в систему и получив access_token и user_id.

Чтобы пользователь мог войти в мое приложение, мне нужно аутентифицировать его на моем конце, поэтому пользователь отправляет этот access_token на мой сервер, где я его проверяю (используя конечную точку /debug_token FB). Это использует 1 вызов против моего ограничения скорости API. Странно, но ладно. Странно, потому что на этом этапе игры я привык видеть JWT, которые можно легко проверить (например, publi c ключи или даже JWK), даже без дополнительного сетевого вызова.

Так как мой собственный бэкэнд предоставляет конечную точку, которая ожидает, что FB access_token, злоумышленник может довольно быстро нарушить мой предел скорости FB , даже просто передав что-либо, составленное как access_token. Хорошо, может быть, я смогу предотвратить эту проблему, сначала добавив быстрый запрос к конечной точке FB /me?fields=id, и если он вернет действительный user_id, я смогу затем проверить его с помощью конечной точки /debug_token. Отлично, теперь мое количество запросов, сделанных против моего ограничения скорости API, равно 2. Теперь кто-то теоретически может злоупотреблять мной в два раза быстрее (им просто нужен действительный access_token, даже не нужно связывать его с моим app_id).

Я что-то упустил? Я думаю, может быть, в моем потоке авторизации есть очевидный недостаток. Но потом я подумал, что проблема все еще существует, потому что любой, у кого есть такой инструмент, как Charles, может легко узнать, что access_token FB их выпустил, и может просто спамить конечную точку /me?fields=id и увеличить количество моих звонков.

Am Я что-то не так делаю? Любые предложения приветствуются! :)

Изменить:

Не осознавал, что ограничение скорости составляет (200 x общее количество пользователей) в час . Возможно, я переоценил проблему.

...