Возможный подход для защиты конечных точек API-интерфейса Rest с использованием OOuth Facebook

Я много читал о теме, но все, что я нахожу, - это устаревшие или частичные ответы, которые на самом деле не очень помогают мне, а на самом деле меня просто путают. Я пишу Rest API (Node + Express + MongoDB), к которому обращается веб-приложение (размещенное в том же домене, что и API), и приложение для Android.

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

Возможный сценарий, который я имею в виду:

Пользователь регистрируется в веб-приложении с помощью Facebook, приложение предоставляется разрешение на доступ к информации пользователя Facebook и получение токен доступа.
Веб-приложение просит API подтвердить, что этот пользователь на самом деле зарегистрирована в нашей системе, отправив электронное письмо и токен, полученный Facebook.
API проверяет, что пользователь существует, он хранит в БД (или Redis) имя пользователя, токен и отметка времени, а затем возвращается к клиентскому приложению.
Каждый раз, когда клиентское приложение попадает в одну из конечных точек API, оно должно будет предоставить имя пользователя и токен, кроме другой информации.
API каждый раз проверяет, что предоставленное имя/токен пары соответствует самому недавнее имя/токен пары, хранящиеся в БД (используя временную метку на заказ) и что прошло не более 1 часа с момента хранения эти данные (опять же используя временную метку). Если это так, API будет обрабатывать запрос, в противном случае выдается 401 Несанкционированный ответ.

Это имеет смысл? Имеет ли этот подход какое-либо макроскопическое отверстие для безопасности, которое мне не хватает? Одна из проблем, которые я вижу в использовании MongoDB для хранения этих данных, заключается в том, что коллекция быстро раздувается старыми токенами. В этом смысле я думаю, что было бы лучше использовать Redis с истечением срока действия в течение 1 часа, чтобы старая информация автоматически удалялась Redis.

Ответ 1

Я думаю, что лучшим решением было бы следующее:

Войти через Facebook
Передайте Facebook AccessToken на сервер (через SSL для Android-приложение, а для веб-приложения просто перенаправить его на конечную точку API после входа в FB)
Проверьте fb_access_token, убедитесь, что он действителен. Получите user_id, email и перекрестно ссылайтесь на это с существующими пользователями на посмотрите, есть ли новый или старый.
Теперь создайте случайный, отдельный api_access_token, который вы вернете в приложение webapp and android. Если вам нужна Facebook для ничего, кроме входа, сохраните fb_access_token и в своем DB связывает его с новым api_access_token и вашим user_id.
Для каждого последующего вызова отправьте api_access_token для его аутентификации. Если вам нужна fb_access_token для получения дополнительной информации, вы можете сделайте это, извлекая его из БД.

Вкратце: всякий раз, когда вы можете, не пропускайте fb_access_token. Если api_access_token скомпрометирован, у вас больше контроля, чтобы узнать, кто такой злоумышленник, что они делают и т.д., Чем если бы они хотели получить fb_access_token. У вас также больше контроля над установками с датой истечения срока действия, расширяя fb_access_token s и т.д.

Просто убедитесь, что всякий раз, когда вы передаете access_token любого типа через HTTP, используйте SSL.