Давайте посмотрим, что идет не так, и вместо того, чтобы пытаться это исправить, мы рассмотрим совершенно другой подход к проблеме, который, как мы надеемся, будет работать лучше.
Что идет не так (и некоторый фон)
Для традиционной аутентификации с помощью Действия в Google вам необходимо настроить сервер OAuth. Когда пользователь попадает в точку в своем действии, где вам требуется аутентифицированный пользователь, он направляет его на ваш веб-сервер OAuth для входа в систему, ожидает, что ваш сервер отправит обратно маркер доступа или код авторизации, возможно, проделает дополнительную работу, чтобы получить токен авторизации, а затем отправлять вам токен доступа или аутентификации каждый раз, когда вызывается выполнение веб-крюка. Затем вы используете этот токен, чтобы выяснить, кто пользователь, и действовать соответствующим образом.
Похоже, происходит то, что Ассистент отправляет пользователя к вашей точке входа в систему с информацией, которая гласит: «Когда вы закончите, перенаправьте сюда токен доступа». Эта часть кажется в порядке. Вы проходите процесс входа, который включает в себя Google Sign In. В какой-то момент вы перенаправляете обратно на тот же URL, который хочет помощник.
Проблема в том, что вместо отправки токена доступа он отправляет однократный код авторизации. Помощник получает это и, поскольку он не настроен для обработки, выдает ошибку.
Не ясно, почему он отправляет код вместо токена доступа. Может случиться так, что OmniAuth предназначен для использования метода «код авторизации», и вы настроили помощник для использования «неявного» метода. Или же это может быть из-за того, что вход и помощник используют один и тот же URL-адрес как часть процесса, и это сбивает с толку. ИЛИ может случиться так, что OmniAuth на самом деле не призван играть роль сервера OAuth.
Если вы действительно хотите пойти по этому пути, изучите конфигурацию OmniAuth и рассмотрите возможность изменения ее конфигурации или конфигурации действия.
Обновление : Звучит так, будто использовался неверный поток аутентификации, и я рад, что вы исправили это. Авторизованный redirect_uri, который вы должны установить для OmniAuth, должен быть точно , что Google отправляет как часть своего запроса: https://oauth-redirect.googleusercontent.com/r/my_project_id
Однако ... вам это может не понадобиться.
Использование входа в Google для привязки аккаунта
Поскольку вы регистрируете пользователя в своем веб-приложении с помощью Google Sign-In, вы можете избежать всей проблемы с сервером OAuth и воспользоваться доступным ярлыком. Если ваше веб-приложение и ваше Действие являются частью одного и того же Облачного проекта Google, то Google Sign In for Assistant отправит вам идентификационный токен для пользователя, как только они подтвердят свою подлинность в проекте. Они могут аутентифицировать себя либо с помощью голоса в действии, либо войдя в веб-приложение с помощью входа в Google.
Идентификационный токен, который отправляется, не является токеном авторизации. Однако, если вы сохранили токен авторизации и обновили токен от пользователя, вошедшего в ваше веб-приложение, вы можете использовать информацию в идентификаторе токена, чтобы просмотреть эту информацию и использовать ее.
Большая «проблема» в том, что вам нужно запрашивать дополнительные области только через ваше веб-приложение - нет способа сделать это как часть действия. Однако это не является серьезным препятствием - это просто означает, что если пользователь достигает вашего Действия без идентификатора, попросите его сначала войти в ваше веб-приложение.
См. Дальнейшее обсуждение и диаграммы по этому вопросу переполнения стека