Ошибка конечных точек Google: для токена Firebase ID указано неверное утверждение aud (аудитория). Ожидался, но получил

Я видел похожие вопросы, но мой вариант использования кажется другим. Позволь мне объяснить.

  1. У меня ОДИН проект.
  2. Я использую в проекте аутентификацию Firebase
  3. Я создал облачную функцию HTTP на основе Node JS для разных маршрутов.

Используя Postman, я отправляю POST-запрос в функцию Cloud и использую маршрут login, передаю адрес электронной почты и пароль и получаю токен в ответе.

Используя Postman, я выполняю запрос POST к функции Cloud и использую маршрут check, передав токен из предыдущего запроса и аутентифицируя токен. Оно работает. Для этого я использую функцию admin.auth().verifyIdToken клиентского администратора firebase.

Вроде все хорошо.

Теперь, когда я настраиваю конечную точку Google Cloud (в контейнере Google Cloud Run) в том же проекте и:

  1. Я не установил никаких опций ценных бумаг (пока) в yaml-файле Firebase stagger.

  2. Я могу отправить запрос POST в конечную точку Google Cloud, используя путь login, я получаю токен, как и раньше.

  3. Но когда я делаю свой POST-запрос, используя конечную точку по пути check, я получаю сообщение «Идентификационный токен Firebase имеет неверное утверждение aud (аудитория)». ошибка.

Кажется, я перепробовал все варианты, предложенные другими на этих форумах. Я создал закрытый ключ из консоли firebase и инициализировал с его помощью клиент администратора firebase, и все же я получаю ту же ошибку, которая гласит: «Требование предполагается к идентификатору проекта, но оно принимает его как имя функции», которое является частью того же проекта.

Я также настроил свою функцию node js с помощью cors (app.use(cors())), но такая же ошибка сохраняется.

Я занимаюсь этим последние 4-5 дней, но, похоже, не понимаю, в чем именно проблема и почему он не может принять вызов функции клиента администратора. Любой, кто даст мне направление, будет очень признателен. Спасибо.


firebase firebase-authentication google-cloud-functions google-cloud-endpoints google-cloud-endpoints-v2
person RmR    schedule 27.01.2020    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Да, ESP и ESPv2 автоматически заменят заголовок Authorization новым токеном. Это для случая использования, когда серверная служба Cloud Run или облачная функция требуют аутентификации.

Вы можете отключить это автоматическое переопределение токена в x-google-backend с помощью disable_auth. https://cloud.google.com/endpoints/docs/openapi/openapi-extensions#jwt_audience_disable_auth

Однако ваш бэкэнд по-прежнему может получать исходный токен, не отключая эту функцию. Из документации x-google-backend:

Следовательно, если клиент API устанавливает заголовок авторизации, серверная часть, работающая за ESPv2, должна использовать заголовок X-Forwarded-Authorization для получения всего JWT. Серверная часть должна проверить JWT в этом заголовке, поскольку ESPv2 не будет выполнять проверку, если не настроены методы аутентификации.

Если вам нужны только утверждения из исходного токена, см. Получение с проверкой подлинности результаты в вашем API.

ESP обычно пересылает все полученные заголовки. Однако он переопределяет исходный заголовок авторизации, когда внутренний адрес указан x-google-backend в спецификации OpenAPI или BackendRule в конфигурации службы gRPC. ESP отправит результат аутентификации в X-Endpoint-API-UserInfo внутреннему API. Рекомендуется использовать этот заголовок вместо исходного заголовка авторизации.

Поэтому для вашего варианта использования измените свой сервер так, чтобы он читал либо X-Forwarded-Authorization, либо X-Endpoint-API-UserInfo в зависимости от того, какие поля вам нужны. Не читайте заголовок Authorization, если не хотите устанавливать disable_auth.

person nareddyt    schedule 11.02.2020
comment
Спасибо @nareddyt. Но что, если мне нужна аутентификация firebase для доступа к функции Google, на которую путь перенаправляет запрос. В моем варианте использования клиент браузера аутентифицирует пользователя firebase и хочет отправить токен с запросом шлюза API. И сам шлюз api должен отклонить его, если токен недействителен или просрочен. - person RmR; 12.02.2020
comment
Кстати, в настоящее время я отправляю токен из клиента браузера как часть тела запроса POST, а функция Google проверяет этот токен. Как уже упоминалось, я подумал о правильном использовании шлюза Google API для фильтрации такой аутентификации на этом уровне. Это не? - person RmR; 12.02.2020
comment
Я думаю, вы говорите о двух разных вещах. 1) Если вы хотите написать код в своей облачной функции для запуска аутентификации firebase, вам нужно установить disable_auth в ESP, чтобы он не менял токен. 2) Если вы хотите, чтобы ESP выполнял аутентификацию без написания кода в вашей облачной функции, вы тоже можете это сделать. Это предполагаемый вариант использования ESP. Дополнительную информацию см. В этом документе: cloud.google.com/endpoints/docs / openapi / - person nareddyt; 12.02.2020
comment
Еще раз спасибо @nareddyt. Меня интересует последний случай. Поэтому, когда браузер отправляет токен на шлюз API, он выдает указанную выше ошибку, для которой я задал вопрос. Моя работа (аутентификации с помощью функций Google) является временной, пока я занимаюсь этой проблемой. Фактически, я удалил декларации безопасности из файла api yaml, чтобы облегчить это. Спасибо - person RmR; 12.02.2020
comment
Позвольте мне пояснить, что ошибка возникает из-за шлюза API. - person RmR; 12.02.2020
comment
Понятно. Я предлагаю вам публиковать сообщения в группе конечных точек Google Cloud. Пожалуйста, опубликуйте всю конфигурацию вашего сервиса и полную ошибку, которую вы получили, мы поможем вам отладить ее. - person nareddyt; 12.02.2020
comment
Я отредактировал исходный ответ на основе новых функций. Надеюсь, это поможет. - person nareddyt; 17.03.2021

arrow_upward
0
arrow_downward

Мое наблюдение заключалось в том, что токен, который отправляется через заголовки запроса, изменяется сервером конечных точек Google до того, как он будет обработан функциями Google, указанными в пути к файлу Yaml.

Я отправил токен в заголовке, а также в теле письма и обнаружил, что значения различаются, сравнивая их.

Когда я использовал токен, отправленный через тело, клиент firebase-admin обнаружил, что это действительный идентификатор, а когда я использовал токен из заголовка запроса, он выдал указанную выше ошибку.

person RmR    schedule 01.02.2020
comment
Да, это правильно. См. Мой ответ об отключении этого поведения. - person nareddyt; 11.02.2020