En el sitio web https://code.google.com/apis/console , registré mi aplicación, configuré el ID de cliente generado y el secreto de cliente en mi aplicación e intenté iniciar sesión con Google. Desafortunadamente, recibí el mensaje de error:

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

¿Qué significa este mensaje y cómo puedo solucionarlo? Yo uso la gema omniauth-google-oauth2 .

El URI de redireccionamiento (donde se devuelve la respuesta) debe registrarse en la consola de las API, y el error indica que no lo ha hecho o no lo ha hecho correctamente.

Vaya a la consola para su proyecto y busque en API Access. Debería ver su client ID& client secretallí, junto con una lista de URI de redireccionamiento. Si el URI que desea no aparece en la lista, haga clic en editar configuración y agregue el URI a la lista.

EDITAR: (De un comentario altamente calificado a continuación) Tenga en cuenta que actualizar la consola de la API de Google y que el cambio esté presente puede llevar algún tiempo. Generalmente solo unos minutos, pero a veces parece más largo.

En mi caso fue wwwy non-wwwURL. El sitio real tenía wwwURL y los URI de redireccionamiento autorizado en la Consola del desarrollador de Google tenían non-wwwURL. Por lo tanto, hubo una falta de coincidencia en el URI de redireccionamiento. Lo resolví actualizando Authorized Redirect URIsen Google Developer Console a wwwURL.

Otros desajustes comunes de URI son:

• Uso http://en URI de redireccionamiento autorizado y https://como URL real, o viceversa
• Usar barra diagonal ( http://example.com/) en URI de redireccionamiento autorizado y no utilizar barra diagonal ( http://example.com) como URL real, o viceversa

Aquí están las capturas de pantalla paso a paso de Google Developer Console para que sea útil para aquellos que tienen dificultades para localizar la página de la consola del desarrollador para actualizar los URI de redireccionamiento.

1. Vaya a https://console.developers.google.com

2. Selecciona tu proyecto

3. Haga clic en el ícono de menú

4. Haga clic en el API Managermenú

5. Haz clic en el Credentialsmenú. Y debajo OAuth 2.0 Client IDs, encontrará el nombre de su cliente. En mi caso, lo es Web Client 1. Haga clic en él y aparecerá una ventana emergente donde puede editar el origen de Javascript autorizado y los URI de redireccionamiento autorizado .

Aquí hay un artículo de Google sobre la creación de proyectos e ID de clientes .

Si está utilizando el botón JavaScript de Google+ , debe usarlo en postmessagelugar del URI real. Me tomó casi todo el día resolver esto, ya que los documentos de Google no lo indican claramente por alguna razón.

En cualquier flujo en el que recuperó un código de autorización en el lado del cliente, como la GoogleAuth.grantOfflineAccess()API , y ahora desea pasar el código a su servidor, canjearlo y almacenar los tokens de acceso y actualización, debe usar la cadena literal postmessageen lugar de redirect_uri.

Por ejemplo, basándose en el fragmento en el documento de 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's 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"}

La única documentación de Google que menciona postmessagees este antiguo documento de inicio de sesión de Google+ . Aquí hay una captura de pantalla y un enlace de archivo ya que G + se está cerrando y este enlace probablemente desaparecerá:

Es absolutamente imperdonable que la página de documentos para el acceso sin conexión no mencione esto. #FacePalm

Para mi aplicación web, corregí mi error escribiendo

instead of : http://localhost:11472/authorize/
type :      http://localhost/authorize/

Asegúrese de verificar el protocolo "http: //" o "https: //" como protocolo de Google Check también. Es mejor agregar ambas URL en la lista.

Esto parece bastante extraño y molesto porque no hay una solución "única". para mí http: // localhost: 8000 no funcionó pero http: // localhost: 8000 / funcionó.

Cuando registra su aplicación en https://code.google.com/apis/console y crea una ID de cliente, tiene la oportunidad de especificar uno o más URI de redireccionamiento. El valor del redirect_uriparámetro en su URI de autenticación debe coincidir exactamente con uno de ellos.

Esta respuesta es la misma que la respuesta de este Mike , y la respuesta de Jeff , ambos conjuntos redirect_uria postmessageel lado del cliente. Quiero agregar más sobre el lado del servidor, y también las circunstancias especiales que se aplican a esta configuración.

Pila de tecnología

Backend

• Python 3.6
• Django 1.11
• Django REST Framework 3.9 : servidor como API, sin plantilla de representación, sin hacer mucho en otro lugar.
• Django REST Framework JWT 1.11
• Django REST Social Auth <2.1

Interfaz

• Reaccionar : 16.8.3, create-react-appversión 2.1.5
• react-google-login : 5.0.2

El flujo de "Código" (Específicamente para Google OAuth2)

Resumen: Reaccionar -> solicitar "código" de autenticación social -> solicitar token jwt para adquirir el estado de "inicio de sesión" en términos de su propio servidor / base de datos de back-end.

1. Frontend (React) utiliza un "botón de inicio de sesión de Google" responseType="code"para obtener un código de autorización. (¡no es token, no token de acceso!)
   • El botón de inicio de sesión de Google es el react-google-loginmencionado anteriormente.
   • Al hacer clic en el botón, aparecerá una ventana emergente para que el usuario seleccione una cuenta. Después de que el usuario seleccione uno y la ventana se cierre, obtendrá el código de la función de devolución de llamada del botón.
2. Frontend envía esto al punto final JWT del servidor de fondo.
   • Solicitud POST, con { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
3. Para mi servidor Django, uso Django REST Framework JWT + Django REST Social Auth. Django recibe el código de la interfaz, verifíquelo con el servicio de Google (hecho por usted). Una vez verificado, enviará el JWT (el token) de nuevo a la interfaz. Frontend ahora puede cosechar la ficha y almacenarla en algún lugar.
   • Todo REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_ORIGINy REST_SOCIAL_OAUTH_REDIRECT_URIen Django's settings.pyson innecesarios . (Son constantes utilizadas por Django REST Social Auth) En resumen, no tiene que configurar nada relacionado con la URL de redireccionamiento en Django . El "redirect_uri": "postmessage"frontend de In React es suficiente. Esto tiene sentido porque el trabajo de autenticación social que tiene que hacer de su lado es una solicitud POST de estilo Ajax en la interfaz, no envía ningún formulario, por lo que en realidad no se produce una redirección por defecto. Es por eso que la URL de redireccionamiento se vuelve inútil si está utilizando el código + flujo JWT, y la configuración de la URL de redireccionamiento del lado del servidor no está teniendo ningún efecto.
4. Django REST Social Auth maneja la creación de cuentas. Esto significa que verificará el correo electrónico / apellido de la cuenta de Google y verá si coincide con alguna cuenta en la base de datos. Si no, creará uno para usted, utilizando el correo electrónico y el apellido exactos. Pero, el nombre de usuario será algo así como youremailprefix717e248c5b924d60si su correo electrónico es youremailprefix@example.com. Agrega una cadena aleatoria para hacer un nombre de usuario único. Este es el comportamiento predeterminado, creo que puede personalizarlo y no dude en profundizar en su documentación.
5. La interfaz almacena ese token y cuando tiene que realizar CRUD en el servidor de fondo, especialmente crear / eliminar / actualizar, si adjunta el token en su Authorizationencabezado y envía la solicitud al backend, el backend de Django ahora lo reconocerá como un inicio de sesión, es decir, autenticado usuario. Por supuesto, si su token caduca, debe actualizarlo haciendo otra solicitud.

¡Oh Dios mío, he pasado más de 6 horas y finalmente lo hice bien! Creo que es la primera vez que veo esto postmessage. Cualquiera que trabaje en una Django + DRF + JWT + Social Auth + Reactcombinación definitivamente chocará con esto. No puedo creer que nada del artículo mencione esto, excepto las respuestas aquí. Pero realmente espero que esta publicación pueda ahorrarle mucho tiempo si está usando la pila Django + React.

201515 de julio: el inicio de sesión que funcionaba la semana pasada con este script al iniciar sesión

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

dejó de funcionar y comenzó a causar el error 400 con Error: redirect_uri_mismatch

y en la sección DETALLES: redirect_uri=storagerelay://...

Lo resolví cambiando a:

<script src="https://apis.google.com/js/client:platform.js?onload=startApp"></script>

Lista de Verificación:

• httpo https?
• &o &?
• barra inclinada ( /) o abierta ?
• (CMD/CTRL)+F, busque la coincidencia exacta en la página de credenciales. Si no se encuentra, busque el que falta.
• Espere hasta que google lo actualice. Puede ocurrir en cada media hora si cambia con frecuencia o puede permanecer en la piscina. Para mi caso, tardó casi media hora en surtir efecto.

En mi caso, mi tipo de solicitud de credencial es "Otro". Entonces no puedo encontrar Authorized redirect URIsen la página de credenciales. Parece que aparece en Tipo de aplicación: "Aplicación web". Pero puede hacer clic en el Download JSONbotón para obtener el client_secret.jsonarchivo.

Abra el archivo JSON, y se puede encontrar el parámetro de la siguiente manera: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. Elijo usar http: // localhost y funciona bien para mí.

La URL de redireccionamiento distingue entre mayúsculas y minúsculas.

En mi caso, agregué ambos: http: // localhost: 5023 / AuthCallback / IndexAsync http: // localhost: 5023 / authcallback / indexasync

Ninguna de las soluciones anteriores funcionó para mí. abajo hizo

cambie las URL de redireccionamiento autorizadas a - https: // localhost: 44377 / signin-google

Espero que esto ayude a alguien.

cuidado con el extra /al final de la url http://localhost:8000es diferente dehttp://localhost:8000/

Usuarios de Rails (de los documentos omniauth-google-oauth2 ):

Arreglo de error de protocolo para redirect_uri en Rails

Simplemente configure full_host en OmniAuth basado en Rails.env.

# config / initializers / omniauth.rb

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

RECUERDE: No incluya el "/" final

Si usa este tutorial: https://developers.google.com/identity/sign-in/web/server-side-flow, entonces debe usar "postmessage".

En GO, esto solucionó el problema:

confg = &oauth2.Config{
        RedirectURL:  "postmessage",
        ClientID:   ...,
        ClientSecret: ...,
        Scopes:      ...,
        Endpoint:     google.Endpoint,
}

para mí fue porque en la lista 'URI de redireccionamiento autorizado' he colocado incorrectamente en https://developers.google.com/oauthplayground/lugar de https://developers.google.com/oauthplayground(sin /al final).

Permítanme completar la respuesta de @ Bazyl: en el mensaje que recibí, mencionaron el URI "http://localhost:8080/" (que, por supuesto, parece una configuración interna de Google). Cambié el URI autorizado para ese "http://localhost:8080/", y el mensaje ya no apareció ... Y el video se subió ... La documentación de APIS es MUY lamentable ... Cada vez que tengo algo trabajando con google apis, simplemente me siento "afortunado", pero falta una buena documentación al respecto ... :( Sí, lo hice funcionar, pero aún no entiendo por qué falló ni por qué funcionó ... Solo había UNO lugar para confirmar el URI en la web, y se copió en client_secrets.json ... No entiendo si hay un TERCER lugar donde se debe escribir el mismo URI ... No encuentro solo la documentación sino también el Diseño GUI de Google '

Cualquiera que tenga dificultades para encontrar dónde configurar las URL de redireccionamiento en la nueva consola: API y autenticación -> Credenciales -> ID de cliente OAuth 2.0 -> Haga clic en el enlace para encontrar todas sus URL de redireccionamiento

Necesitaba crear una nueva ID de cliente en API y servicios -> Credenciales -> Crear credenciales -> OAuth -> Otro

Luego descargué y utilicé client_secret.json con mi programa de línea de comandos que se está cargando en mi cuenta de YouTube. Estaba tratando de usar un ID de cliente OAuth de aplicación web que me estaba dando el error de redireccionamiento URI en el navegador.

Intenta hacer estos controles:

1. ID de paquete en la consola y en su aplicación. Prefiero establecer la ID del paquete de la aplicación como esta "org.peredovik. $ {PRODUCT_NAME: rfc1034identifier}"
2. Verifique si agregó tipos de URL en la pestaña Información simplemente escriba su ID de paquete en Identificador y Esquemas de URL, conjunto de roles en Editor
3. En la consola en cloud.google.com "APIs y autenticación" -> "Pantalla de consentimiento" rellene el formulario sobre su solicitud. El "nombre del producto" es un campo obligatorio.

Disfruta :)

En mi caso, tuve que verificar el tipo de ID de cliente para aplicaciones web / aplicaciones instaladas.

aplicaciones instaladas: http: // localhost [Redirigir URI] En este caso, localhost simplemente funciona

aplicaciones web: necesita un nombre de dominio válido [URI de redireccionamiento:]

Lo que debe hacer es volver a su Consola de desarrollador e ir a APIs y autenticación> Pantalla de consentimiento y completarlo. Específicamente, el nombre del producto.

No olvide incluir la ruta después de su dominio e ip. En mi caso, olvidé:

/ oauth2callback

Tenía dos URI de solicitud en la consola, http: // xxxxx / client / api / spreadsheet / authredirect y http: // localhost .

Intenté todas las respuestas principales a esta pregunta y confirmó que ninguna de ellas era mi problema.

Eliminé localhost de la consola, actualicé mi client_secret.json en mi proyecto y desapareció el error de falta de coincidencia.

Tuve el mismo problema con el inicio de sesión de Google, estaba a punto de arrancarme el pelo. Ingresé correctamente mis devoluciones de llamada en el panel de credenciales de Google en la consola de desarrolladores de Google, aquí estaban mis URL de redireccionamiento:

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

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

https://www.example.com/oauth2callback

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

todo parece estar bien, ¿verdad? pero aún no funcionaba hasta que he añadido una más mágica Url añadí signin-google url (que es por defecto Google devolución de llamada) y sin www y problema resuelto.

téngalo en cuenta (dependiendo de su dominio) puede que necesite o no agregar ambos con y sin www urls

Tengo una aplicación frontend y una API de backend.

Desde mi servidor de back-end estaba probando presionando la API de Google y enfrentaba este error. Durante todo mi tiempo me preguntaba por qué debería tener que dar, redirect_uriya que esto es solo el back-end, ya que la interfaz tiene sentido.

Lo que estaba haciendo era dar un redirect_uriservidor diferente (aunque válido) (suponiendo que esto sea solo un marcador de posición, solo tiene que estar registrado en Google), pero mi URL de la interfaz que creó el código de token fue diferente. Entonces, cuando pasaba este código en las pruebas del lado del servidor (para las cuales redirect-uri era diferente), me enfrentaba a este error.

Así que no cometas este error. Asegúrese de que su interfaz redirect_urisea ​​la misma que la de su servidor, ya que Google la usa para validar la autenticidad.

A continuación se detallan los motivos del error: se produce el problema de redirect_uri_mismatch:

1. Redireccione el campo URL en blanco en su proyecto de Google.
2. La URL de redireccionamiento no coincide con su sitio
3. ¡Importante! Funcionará solo con un dominio de trabajo como example.com, book.com, etc. (No funciona con el host local o la URL de AWS LB)

Recomendado para usar la URL del dominio

El truco consiste en ingresar la URL de redireccionamiento correcta al momento de crear la ID. Descubrí que actualizar la URL de redireccionamiento una vez que se ha creado la ID a través de una 'Edición' simplemente no hace el trabajo. Lo que también funcionó para mí es duplicar toda la carpeta 'proveedor' y copiarla en la misma ubicación donde está el archivo 'oauth' (solo hasta que genere con éxito el token y luego pueda eliminar la carpeta duplicada 'proveedor'). Esto se debe a que intentar señalar la carpeta del proveedor a través de '../vendor/autoload' no funcionó para mí.

Por lo tanto, elimine su problemática ID de cliente OAuth existente y pruebe este enfoque, funcionará.