Ответ 1
Короткий ответ - да. Полный ответ заключается в том, что в большинстве случаев у нас есть более подходящий инструмент. Поэтому многое зависит от используемого варианта использования, который вы пытаетесь решить.
Новая версия SDK немного более мощная, и мы не сделали большой работы по обобщению возможностей. Это похоже на хорошее место для сравнения доступных инструментов и их использования, а затем я буду придерживаться некоторых замечаний сторонних разработчиков (т.е. Go) в конце.
Использование внешнего средства проверки подлинности для проверки подлинности клиента
Основное использование чеков пользовательских токенов - это позволить пользователям проходить аутентификацию против внешнего/устаревшего механизма авторизации, например, вашего LDAP-сервера. Основной процесс для этого описан здесь: iOS, Android, Web.
По сути, ваша служба просто набирает токен JWT и передает его клиенту. Клиент выполняет проверку/аутентификацию с помощью настраиваемого маркера.
Аутентификация ваших привилегированных работников
Больше не нужно использовать пользовательские токены для аутентификации вашего серверного процесса. Это делается путем создания учетной записи службы, которая поэтапно рассматривается в Добавление Firebase на ваш сервер. Когда закончите, вы получите файл JSON, содержащий закрытый ключ.
Затем вы включаете учетные данные учетной записи службы, ссылаясь на этот JSON, используя атрибут serviceAccount в firebase.initializeApp(), и вы находитесь! Это описано здесь и выглядит так (см. Ссылку для версии Java):
var firebase = require("firebase");
// Initialize the app with a service account, granting admin privileges
firebase.initializeApp({
databaseURL: "https://databaseName.firebaseio.com",
serviceAccount: "./serviceAccountCredentials.json"
});
Эмуляция пользователей или ограничение доступа к серверному процессу
Это довольно тривиально, чтобы эмулировать пользователя или ограничить доступ (рекомендуется) из серверного процесса. Вам действительно не нужно больше накладывать на него пользовательский токен.
Это просто требует добавления databaseAuthVariableOverride в ваш вызов database.initializeApp():
firebase.initializeApp({
databaseURL: "https://databaseName.firebaseio.com",
serviceAccount: "./serviceAccountCredentials.json",
databaseAuthVariableOverride: {
uid: "my-service-worker-or-user-uid"
}
});
Проверка идентификатора клиента с помощью безопасности
Прежде всего, вы можете избежать проверки на стороне сервера, если используете базу данных Firebase, путем записи клиентом своего клиента в базу данных и использования правил безопасности для проверки их личности. Если ваш сервер прослушивает путь, требующий аутентификации для записи, то это уже разрешено без какой-либо специальной защиты на сервере.
Путем моделирования этого как очереди событий он создает простую, модульную и масштабируемую стратегию рабочего сервера. См. firebase-queue для некоторых замечательных инструментов Node.js. Он поддерживает 3.x.
Проверка токенов ID клиента на сервере
Если вы не используете базу данных реального времени и должны получать токены клиентов (например, через вызовы REST) и убедитесь, что они действительны, вы можете сделать это, используя verifyIdToken(), как описано здесь. Это будет выглядеть следующим образом:
auth.verifyIdToken(idToken).then(function(decodedToken) {
var uid = decodedToken.sub;
});
Если вы хотите выполнить аутентификацию в качестве этого пользователя для записи в базу данных и обеспечения безопасности, вы должны использовать раздел "Эмуляторы" выше. Другими словами, вызовите initializeApp() с databaseAuthVariableOverride, установленным в соответствующий uid.
Обратите внимание, что если вы попытаетесь вызвать initializeApp() несколько раз и выполните ошибку, подобную следующей: Error: Firebase App named '[DEFAULT]' already exists. Вы можете инициализировать несколько контекстов приложения, добавив второй аргумент к вызову initializeApp() (например, database.initializeApp({...}, 'asUser'+uid)), а затем ссылайтесь на этот экземпляр приложения, используя firebase.database('asUser'+uid).ref(...). Чтобы узнать больше об использовании нескольких экземпляров приложения, смотрите здесь.
Java-код доступен по ссылкам выше. Go и другие сторонние решения, рассмотренные ниже.
Создание маркера для использования в REST API
Майкл Блей рассмотрел этот сценарий здесь и заслужил некоторую репутацию за это.
Создание жетонов или их проверка через REST
Это не поддерживается. К сожалению.
Голан и другие: еще впереди
Мы работаем над библиотекой чеканки и проверки токенов. Мы также добавим инструменты Python для этого в ближайшее время. Для этого нет даты выхода или для нее. В то же время, если вы хотите проверить токены идентификатора клиента, не используя официальные библиотеки Firebase Node.js или Java (которые имеют встроенные методы проверки), вам необходимо будет убедиться, что маркер ID (который является JWT) соответствует следующему:
- Его декодированный заголовок имеет требование
alg(algorithm), равное"RS256". - Его декодированная полезная нагрузка имеет требование
aud(аудитория), равное вашему ID проекта Firebase. - Его декодированная полезная нагрузка имеет требование
iss(эмитента), равное"https://securetoken.google.com/<projectId>". - Его декодированная полезная нагрузка имеет непустую строку
sub(subject). Обратите внимание, что этоuidдля этого пользователя Firebase. - Его декодированный заголовок имеет запрос
kid(идентификатор ключа), который соответствует одному из открытых ключей, перечисленных вhttps://www.googleapis.com/robot/v1/metadata/x509/[email protected]. - Вам также необходимо использовать библиотеку JWT для проверки токена с открытым ключом, чтобы доказать, что токен был подписан с закрытым ключом открытых ключей.
Для Go, похоже, вы можете использовать jwt-go для декодирования и проверки токена идентификатора клиента.