Как хранить токены доступа в серверной части Firebase?

Question

Приложение My React использует аутентификацию Firebase и базу данных в реальном времени. Теперь мне нужно получить доступ к сторонним службам с помощью OAuth 2.0. Чтобы сделать это безопасно, я использую поток кода авторизации OAuth 2.0 с функциями Firebase в качестве серверной части:

1. Приложение React получает код авторизации от третьей стороны.
2. Авторизация код передается в функцию Firebase для получения токена доступа.

Но именно здесь я застрял. Как сохранить токен доступа в бэкэнде, чтобы приложение React могло получить доступ к сторонним ресурсам? Я не хочу хранить токен доступа в приложении React, потому что это небезопасно.

1. Как мне поддерживать сеанс в серверной части с помощью функций Firebase?
2. Следует сеанс будет привязан к экземпляру приложения React или пользователю Firebase? Первый подход потребует очистки сеанса. Последнее имеет то преимущество, что новые токены доступа можно получить с помощью токена refre sh. Таким образом, пользователю больше никогда не нужно будет входить в систему третьей стороны!

Answer 1

Попробовав кучу разных подходов, я в конечном итоге сохранил токен доступа и токен refre sh в серверной части, оба привязаны к пользователю firebase. Токены доступны только через функции firebase. Этот подход имеет следующие преимущества:

1. Безопасный
2. Мне не нужно беспокоиться о сеансах и их очистке.
3. Я могу обновить sh доступ токен всякий раз, когда я хочу использовать токен refre sh.

Answer 2

ОБЩИЕ ФАКТОРЫ

Обычно это области, на которые влияет ваш выбор безопасности SPA, и есть компромиссы:

• Тип приложения
• Надежная безопасность
• Хостинг и глобальная производительность
• Техническая простота

ВО ВСЕХ СЛУЧАЯХ

Ваше приложение должно :

• Поддерживать токен для каждого пользователя отдельно
• Вы захотите идентифицировать пользователей по токенам после входа в систему

ВАРИАНТ 1: ПЕРЕДНИЙ КОНЕЦ МОДЕЛЬ / БЕЗ ПЕЧАТИ

Это включает в себя использование токенов в браузере и дает следующие преимущества:

• Серверная часть является статической c только содержимое
• Веб-ресурсы может быть развернут рядом с пользователями через CDN
• Вы можете использовать OID C Клиентскую библиотеку для управления безопасностью

Это широко используется и должно только быть уязвимым, если в вашем приложении есть уязвимости межсайтового скриптинга. Некоторые мои ресурсы:

• Цели SPA
• Код аутентификации в памяти
• Запись образца кода Вверх

ВАРИАНТ 2: МОДЕЛЬ ЗАДНЕГО КОНЦА / АВТОМАТИЧЕСКИЕ КУКИ

Это включает проксирование через серверную часть и перенос токенов в файлах cookie аутентификации. Я бы использовал эту модель при разработке приложения для онлайн-банкинга, но для приложений со средней степенью безопасности это может добавить много накладных расходов. Возможно, вам придется написать больше кода безопасности, и вы можете получить менее безопасное решение, чем вариант 1:

• Требуется серверная часть прокси, которая запускает код
• Серверная часть код может потребоваться кластеризовать и глобально распределить для достижения хорошей производительности
• Вам необходимо защитить auth cook ie и справиться с рисками подделки межсайтовых запросов

Из интереса уважаемая библиотека mod_auth_openid c может быть полезна для этого типа решения.

ЛУЧШИЙ ИЗ ОБОИХ МИРОВ

Если использование токенов в браузере считается неприемлемым, я бы постарался максимально следовать варианту 1. Затем реализуйте вариант 2 как дополнительный шаг:

• Развернуть содержимое веб-статистики c отдельно от кода, который управляет внутренними токенами
• Продолжить использовать OID C Клиент библиотека, и сделать так, чтобы обмен кодами авторизации вызывал ваш бэкэнд
• Единственное отличие от варианта 1 состоит в том, что маркеры недоступны для кода браузера