Получите токен после успешного входа в Google IAP
Контекст
Интерфейс, работающий в Google Cloud Run, и серверная часть, работающая в Google Cloud Run, оба защищены IAP и требуют аутентификации. Они также оба находятся за балансировщиком нагрузки с сопоставлением API с маршрутом /api/*. Интерфейс обслуживается простым контейнером Nginx.
Проблема
Пользователь успешно входит в систему с помощью IAP во внешнем интерфейсе, но токен JWT теряется в процессе. Вызовы API перенаправляются на экран входа в систему, но, поскольку это вызовы XHR, они застревают на вкладке сети. Поэтому необходим заголовок авторизации с токеном JWT.
Вопрос
Какой самый простой/простой способ совершать вызовы API с помощью токена авторизованного пользователя?
да, файлы cookie отправляются, единственная проблема, которую я вижу, это, возможно, проблема CORS, потому что параметры HTTP не включены в IAP
Вот ошибка из консоли: Запрос перекрестного происхождения заблокирован: политика одного и того же происхождения запрещает чтение удаленного ресурса по адресу «account.google.com/o/oauth2/v2/auth?.... (Причина: учетные данные не поддерживается, если заголовок CORS «Access-Control-Allow-Origin» имеет значение «*»).
IAP должен разрешить все источники. Настройте его здесь: cloud.google.com/iap/docs/customizing#customizing_settings
Я устанавливал withCredentials: true в своем интерфейсе, но его удаление привело к другой ошибке: (Причина: предварительный ответ CORS не удался). Код состояния: 405. Теперь ясно, что запросы OPTIONS должны быть включены.
Помогли ли вам комментарии Гийома решить вашу проблему? Если нет, проверьте эту ссылку на стек , которая поможет вам решить вашу проблему.
да, он мне очень помогает, это очень ценно. Учитывая вашу ссылку, да, мое приложение настроено для правильной обработки запросов CORS OPTIONS. После включения запросов OPTIONS в IAP теперь я получаю Причина: заголовок CORS «Access-Control-Allow-Origin» отсутствует.
Поскольку ваша проблема решена, можете ли вы опубликовать выполненную процедуру как Решение и принять ее?
Проблема до сих пор не решена, но обязательно выложу решение, когда все заработает
похоже, что IAP не отправляет заголовки Allow Origin..
или даже лучше accounts.google.com не разрешает CORS, что нормально, потому что его не следует вызывать в запросах XHR, или я ошибаюсь?
хм... Я думаю, чтобы эта работа работала, между API и внешним интерфейсом должна быть привязка сеанса, потому что файл cookie не распознается. Следовательно, он снова перенаправляет меня на аутентификацию (с запросами XHR), потому что они находятся в двух разных отрицательных числах?
Вероятно, это также связано с тем, что я использую 2 серверные службы в балансировщике нагрузки, а это означает 2 разных IAP.
Ответы 1
Решение заключалось в том, чтобы создать единую службу запуска в облаке, которая обслуживает API и статические файлы, поскольку IAP генерирует одну службу для каждого экземпляра запуска в облаке, поэтому архитектура была слишком сложной, а запуск облака, выделенного для службы внешнего интерфейса, был слишком сложным. .
Другой подход — иметь облачное хранилище и настроить общедоступную облачную CDN, но это добавляет накладные расходы на подписание файлов cookie для получения статических файлов, что не приносит особой пользы, поскольку файлы cookie могут быть украдены. Аутентификация не является принудительной в облачном хранилище, поскольку IAP на данный момент не поддерживает облачное хранилище.
Вы отправляете файлы cookie во время вызовов XHR? Здесь не требуется JWT: IAP аутентифицирует пользователя с помощью файлов cookie и создает для пользователя токен, а затем пересылает его в Cloud Run. Разумеется, идентификатор пользователя должен быть авторизован во внешних и внутренних службах Cloud Run.