Авторизация Google OAuth 2 - Ошибка: redirect_uri_mismatch

На веб-сайте https://code.google.com/apis/console Я зарегистрировал свое приложение, настроил сгенерированный идентификатор клиента: и Client Secret в мое приложение и попытался войти в систему с Google. К сожалению, я получил сообщение об ошибке:

Error: redirect_uri_mismatch
The redirect URI in the request: http://127.0.0.1:3000/auth/google_oauth2/callback did not match a registered redirect URI

scope=https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email
response_type=code
redirect_uri=http://127.0.0.1:3000/auth/google_oauth2/callback
access_type=offline
approval_prompt=force
client_id=generated_id

Что означает это сообщение и как его исправить? Я использую gem omniauth-google-oauth2.

+351
источник поделиться
35 ответов
  • 1
  • 2

URI перенаправления (куда возвращается ответ) должен быть зарегистрирован в консоли API, и ошибка указывает на то, что вы этого не сделали или сделали не правильно.

Перейдите в консоль для вашего проекта и посмотрите под API Access. Там вы должны увидеть свой client ID client secret вместе со списком URI перенаправления. Если требуемый URI отсутствует в списке, нажмите "Изменить настройки" и добавьте URI в список.

РЕДАКТИРОВАТЬ: (Из комментария с высокой оценкой ниже) Обратите внимание, что обновление консоли API Google и это изменение может занять некоторое время. Обычно всего несколько минут, но иногда кажется, что это дольше.

+355
источник

В моем случае это был www и non-www URL. Фактический сайт имел www URL, а Авторизованные URI-адреса перенаправления в Google Developer Console имели non-www URL. Следовательно, было несоответствие в URI перенаправления. Я решил это, обновив Authorized Redirect URIs в Google Developer Console до www URL.

Другим общим несоответствием URI являются:

  • Использование http:// в Уполномоченных URI перенаправления и https:// в качестве фактического URL-адреса или наоборот
  • Использование конечной косой черты (http://example.com/) в URI с авторизованным перенаправлением и не использовать конечную косую черту (http://example.com) в качестве фактического URL-адреса или наоборот

Ниже приведены пошаговые скриншоты в Google Developer Console, поэтому было бы полезно, если бы пользователям было трудно найти страницу консоли разработчика для обновления URI редиректа.

Выберите свой проект

  1. Нажмите на значок меню

Нажмите значок меню

  1. Нажмите API Manager меню

Выбрать меню API-менеджера

  1. Нажмите Credentials меню. И под OAuth 2.0 Client IDs вы найдете свое имя клиента. В моем случае это Web Client 1. Нажмите на него, и появится всплывающее окно, в котором вы сможете редактировать Авторизованный Javascript Origin и Разрешенные URI-адреса перенаправления.

Выбрать меню учетных данных

Вот статья Google о создании проекта и идентификатора клиента.

+98
источник

Если вы используете кнопку Google+ javascript, то вместо фактического URI вы должны использовать postmessage. Мне потребовался почти целый день, чтобы понять это, поскольку Google-документы не ясно излагают это по какой-то причине.

+85
источник

Для моего веб-приложения я исправил свою ошибку, написав

instead of : http://localhost:11472/authorize/
type :      http://localhost/authorize/
+39
источник

В любом потоке, в котором вы GoogleAuth.grantOfflineAccess() код авторизации на стороне клиента, например API GoogleAuth.grantOfflineAccess(), и теперь вы хотите передать код на свой сервер, выкупить его, сохранить токены доступа и обновить, затем вы получите использовать postmessage строку postmessage вместо redirect_uri.

Например, на основе фрагмента в документе Ruby:

client_secrets = Google::APIClient::ClientSecrets.load('client_secrets.json')
auth_client = client_secrets.to_authorization
auth_client.update!(
  :scope => 'profile https://www.googleapis.com/auth/drive.metadata.readonly',
  :redirect_uri => 'postmessage' # <---- HERE
)

# Inject user auth_code here:
auth_client.code = "4/lRCuOXzLMIzqrG4XU9RmWw8k1n3jvUgsI790Hk1s3FI"
tokens = auth_client.fetch_access_token!
# { "access_token"=>..., "expires_in"=>3587, "id_token"=>..., "refresh_token"=>..., "token_type"=>"Bearer"}

Единственная документация Google, в которой даже упоминается postmessage - это старый Google+ документ для входа. Вот скриншот и ссылка на архив, так как G+ закрывается, и эта ссылка, вероятно, исчезнет:

Legacy Google+ API DOC

Абсолютно непростительно, что страница документации для автономного доступа не упоминает об этом. #FacePalm

+37
источник

Обязательно проверьте протокол "http://" или "https://" как протокол проверки google. Лучше добавить оба URL в список.

+29
источник

Это кажется довольно странным и раздражающим, что нет "одного" решения. для меня http://localhost:8000 не сработало, но http://localhost:8000/ разработано.

+7
источник

При регистрации своего приложения в https://code.google.com/apis/console и введите идентификатор клиента, вы получите возможность указать один или несколько перенаправлений URIs. Значение параметра redirect_uri в вашем URI авторизации должно точно соответствуют одному из них.

+6
источник

2015July15 - подпись, которая работала на прошлой неделе с этим script при входе

<script src="https://apis.google.com/js/platform.js" async defer></script>

перестает работать и начинает вызывать ошибку 400 с помощью Error: redirect_uri_mismatch

и в разделе DETAILS: redirect_uri=storagerelay://...

я решил это, изменив на:

<script src="https://apis.google.com/js/client:platform.js?onload=startApp"></script>
+5
источник

Контрольный список:

  • http или https?
  • & или &amp;?
  • конечная косая черта (/) или откройте ?
  • (CMD/CTRL)+F, найдите точное совпадение на странице учетных данных. Если не найден, затем найдите отсутствующий.
  • Подождите, пока Google не обновит его. Может случиться каждые полчаса, если вы часто меняются или могут оставаться в бассейне. Для моего случая было почти полчаса вступить в силу.
+5
источник

URL-адрес перенаправления чувствителен к регистру.

В моем случае я добавил оба: http://localhost:5023/AuthCallback/IndexAsync http://localhost:5023/AuthCallback/IndexAsync

+4
источник

Ни один из вышеперечисленных решений не работал у меня. ниже

изменить разрешенные URL-адреса перенаправления на - https://localhost:44377/signin-google

Надеюсь, это поможет кому-то.

+3
источник

Если вы используете этот учебник: https://developers.google.com/identity/sign-in/web/server-side-flow, тогда вы должны использовать "postmessage".

В GO это исправило проблему:

confg = &oauth2.Config{
        RedirectURL:  "postmessage",
        ClientID:   ...,
        ClientSecret: ...,
        Scopes:      ...,
        Endpoint:     google.Endpoint,
}
+3
источник

Этот ответ совпадает с ответом Майка, и ответ Джеффа, оба устанавливает redirect_uri для postmessage на стороне клиента. Я хочу добавить больше о стороне сервера, а также об особых обстоятельствах, применимых к этой конфигурации.

Tech Stack

Backend

Внешний интерфейс

Поток "Код" (специально для Google OAuth2)

Описание: React → запросить "код" социальной авторизации → запросить токен jwt для получения статуса "логин" с точки зрения вашего собственного внутреннего сервера/базы данных.

  1. Frontend (React) использует "кнопку входа Google" с responseType="code" для получения кода авторизации. (это не токен, не токен доступа!)
    • Кнопка входа в react-google-login указана выше как react-google-login.
    • Нажатие на кнопку откроет всплывающее окно для пользователя, чтобы выбрать учетную запись. После того, как пользователь выберет один и окно закроется, вы получите код из функции обратного вызова кнопки.
  2. Интерфейс отправляет это на конечную точку JWT внутреннего сервера.
    • POST-запрос с { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
  3. Для моего сервера Django я использую Django REST Framework JWT + Django REST Social Auth. Django получает код от внешнего интерфейса, проверьте его с помощью сервиса Google (сделано для вас). После проверки он отправит JWT (токен) обратно во внешний интерфейс. Теперь интерфейс может собрать токен и хранить его где-нибудь.
    • Все REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_ORIGIN и REST_SOCIAL_OAUTH_REDIRECT_URI в Django settings.py не нужны. (Это константы, используемые Django REST Social Auth) Короче говоря, вам не нужно ничего настраивать, связанные с перенаправлением URL в Django. "redirect_uri": "postmessage" в интерфейсе React достаточно. Это имеет смысл, поскольку социальная аутентификационная работа, которую вы должны выполнить на своей стороне, - это все POST-запросы в стиле Ajax во внешнем интерфейсе, не отправляющие никаких форм, поэтому фактически перенаправление по умолчанию не происходит. Вот почему URL-адрес перенаправления становится бесполезным, если вы используете поток кода + JWT, а настройка URL-адреса перенаправления на стороне сервера не дает никакого эффекта.
  4. Django REST Social Auth управляет созданием аккаунта. Это означает, что он проверит адрес электронной почты/фамилию учетной записи Google и выяснит, соответствует ли она какой-либо учетной записи в базе данных. Если нет, он создаст его для вас, используя точную электронную почту и фамилию. Но имя пользователя будет выглядеть как youremailprefix717e248c5b924d60 если ваш адрес электронной почты - [email protected]. Он добавляет некоторую случайную строку для создания уникального имени пользователя. Это поведение по умолчанию, я считаю, что вы можете настроить его и свободно копаться в их документации.
  5. Внешний интерфейс хранит этот токен, и когда он должен выполнить CRUD для внутреннего сервера, особенно создать/удалить/обновить, если вы присоедините токен в заголовке Authorization и отправите запрос к внутреннему интерфейсу, серверная часть Django теперь распознает его как имя входа, т.е. аутентифицированный пользователь. Конечно, если ваш токен истекает, вы должны обновить его, сделав еще один запрос.

О, боже мой, я потратил более 6 часов и наконец понял это правильно! Я полагаю, что это первый раз, когда я увидел это postmessage. Любой, кто работает над комбинацией Django + DRF + JWT + Social Auth + React, обязательно столкнется с этим. Я не могу поверить, что ни одна из статей там не упоминает об этом, кроме ответов здесь. Но я очень надеюсь, что этот пост сэкономит вам массу времени, если вы используете стек Django + React.

+3
источник

Удаляет пользователей (из omniauth-google-oauth2 docs):

Несоответствие протокола Fixing для redirect_uri в Rails

Просто установите full_host в OmniAuth на основе Rails.env.

# config/initializers/omniauth.rb

OmniAuth.config.full_host = Rails.env.production?? 'https://domain.com': 'http://localhost:3000'

ПОМНИТЕ: Не включайте конечный "/"

+2
источник

В моем случае мой учетный тип Тип приложения - "Другое". Поэтому я не могу найти Authorized redirect URIs на странице учетных данных. Кажется, это выглядит в виде приложения: "Веб-приложение". Но вы можете нажать кнопку Download JSON, чтобы получить файл client_secret.json. введите описание изображения здесь

Откройте json файл, и вы можете найти такой параметр: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. Я предпочитаю использовать http://localhost, и он отлично подходит для меня.

+2
источник

остерегайтесь дополнительных / в конце URL-адреса http://localhost:8000 отличается от http://localhost:8000/

+2
источник

Позвольте мне заполнить @Bazyl ответ: в сообщении, которое я получил, они упомянули URI "http://localhost:8080/" (что, конечно, кажется внутренней конфигурацией Google). Я изменил разрешенный URI для этого, "http://localhost:8080/", и сообщение больше не появилось... И видео загрузилось... Документация APIS ОЧЕНЬ хрома... Каждый раз, когда у меня что-то работает с google apis, я просто чувствую себя "счастливым", но есть недостаток хорошей документации об этом....:( Да, я получил его работу, но я еще не понимаю ни, почему это не удалось, ни почему это сработало... Было только ОДНО место, чтобы подтвердить URI в в Интернете, и он был скопирован в client_secrets.json... Я не понимаю, есть ли ТРЕТЬЕ место, где нужно написать тот же URI... Я нахожу, но не только документацию, но и графический интерфейс Google api вполне хромой...

+1
источник

Кто-то изо всех сил пытается найти, где задать URL-адреса перенаправления в новой консоли: API и Auth → Учетные данные → Идентификаторы клиента OAuth 2.0 → Нажмите ссылку, чтобы найти все ваши URL-адреса перенаправления

+1
источник

Мне нужно было создать новый идентификатор клиента в API и службах → Учетные данные → Создать учетные данные → OAuth → Другое

Затем я загрузил и использовал client_secret.json с моей программой командной строки, которая загружается на мою учетную запись youtube. Я пытался использовать идентификатор клиента OAuth для веб-приложений, который давал мне ошибку URI перенаправления в браузере.

+1
источник

для меня это произошло потому, что в списке "Авторизованные переадресации URI" я неправильно разместил https://developers.google.com/oauthplayground/ вместо https://developers.google.com/oauthplayground (без / в конце),

+1
источник

Попробуйте выполнить следующие проверки:

  • Идентификатор пакета в консоли и в вашем приложении. Я предпочитаю установить Bundle ID приложения как этот "org.peredovik. ${PRODUCT_NAME: rfc1034identifier}"
  • Убедитесь, что вы добавили типы URL-адресов на вкладке Info, просто введите свой идентификатор Bundle в идентификаторе и схемах URL-адресов, роль установлена ​​в редакторе
  • В консоли на cloud.google.com "APIs and auth" → "Экран согласия" заполните форму о вашем приложении. "Имя продукта" - обязательное поле.

Наслаждайтесь:)

0
источник

В моем случае мне пришлось проверять тип идентификатора клиента для веб-приложений/установленных приложений.

установленные приложения: http://localhost [Перенаправление URI] В этом случае localhost просто работает

веб-приложения: вам нужно действительное имя домена [URI перенаправления:]

0
источник

Что вам нужно сделать, вернитесь в свою консоль разработчика и перейдите на API и Auth > Consent Screen и заполните это. В частности, название продукта.

0
источник

Не забудьте указать путь после домена и ip. В моем случае я забыл:

/oauth2callback

0
источник

У меня было два URI запроса в консоли, http://xxxxx/client/api/spreadsheet/authredirect и http://localhost.

Я попробовал все ответы на этот вопрос и подтвердил, что ни одна из них не была моей проблемой.

Я удалил localhost из Консоли, обновил my client_secret.json в своем проекте, и ошибка несоответствия исчезла.

0
источник

У меня была такая же проблема с входом google, я собирался вытащить волосы! Я правильно ввел свои обратные вызовы в панели Google Credential на консоли разработчика Google здесь были мои URL-адреса перенаправления:

https://www.example.com/signin-google

https://www.example.com/signin-google/

https://www.example.com/oauth2callback

https://www.example.com/oauth2callback/

Кажется, все прекрасно? но он все еще не работал, пока я не добавил еще один магический Url. Я добавил signin-google url (который является обратным вызовом google по умолчанию) без www и проблема решена.

принять во внимание (в зависимости от вашего домена), вам может потребоваться или не нужно добавлять как с URL-адресами, так и без них

0
источник

У меня есть приложение frontend и backend api.

На моем серверном сервере я тестировал, нажав google api и столкнулся с этой ошибкой. В течение всего моего времени я задавался вопросом, почему мне нужно дать redirect_uri поскольку это всего лишь бэкэнд, для интерфейса это имеет смысл.

То, что я делал, давало разные redirect_uri (хотя и действительные) с сервера (при условии, что это просто placeholder, его просто нужно зарегистрировать только в google), но мой внешний код, который создал токен-код, был другим. Поэтому, когда я проходил этот код в своем тестировании на стороне сервера (для которого перенаправление-uri было другим), я столкнулся с этой ошибкой.

Так что не делайте этой ошибки. Убедитесь, что интерфейс redirect_uri такой же как ваш сервер, как Google использовать его для проверки подлинности.

0
источник

Ниже приводятся причины ошибки: возникает проблема redirect_uri_mismatch:

  1. Перенести URL-адрес в проект google.
  2. URL-адрес перенаправления не совпадает с вашим сайтом
  3. Важный! Он будет работать только с рабочим доменом, например example.com, book.com и т.д. (Не работает с локальным хостом или URL-адресом AWS LB)

Рекомендуется использовать URL-адрес домена

0
источник

Хитрость заключается в том, чтобы ввести правильный URL-адрес перенаправления в точке создания идентификатора. Я обнаружил, что обновление URL-адреса перенаправления после того, как идентификатор был создан с помощью "Редактировать", просто не выполняет работу. Для меня также работало дублирование всей папки "vendor" и копирование ее в то же место, где находится файл "oauth" (до тех пор, пока вы успешно не сгенерируете токен, а затем не сможете удалить дубликат папки "vendor"). Это потому, что попытка указать на папку поставщика через "../vendor/autoload" не сработала для меня.

Итак, удалите существующий проблемный идентификатор клиента OAuth и попробуйте этот подход, он будет работать.

0
источник
  • 1
  • 2

Посмотрите другие вопросы по меткам или Задайте вопрос