Sur le site Web https://code.google.com/apis/console, j'ai enregistré mon application, configuré l' identifiant client généré et le secret client pour mon application et essayé de me connecter avec Google. Malheureusement, j'ai reçu le message d'erreur:

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

Que signifie ce message et comment puis-je le corriger? J'utilise la gemme omniauth-google-oauth2 .

L'URI de redirection (où la réponse est renvoyée) doit être enregistré dans la console des API et l'erreur indique que vous ne l'avez pas fait ou que vous ne l'avez pas fait correctement.

Accédez à la console de votre projet et regardez sous API Access. Vous devriez voir votre client ID& client secretlà, ainsi qu'une liste d'URI de redirection. Si l'URI souhaité n'est pas répertorié, cliquez sur modifier les paramètres et ajoutez l'URI à la liste.

EDIT: (D'après un commentaire très bien noté ci-dessous) Notez que la mise à jour de la console google api et que la modification est présente peut prendre un certain temps. Généralement seulement quelques minutes mais parfois cela semble plus long.

Dans mon cas, c'était wwwet non-wwwURL. Le site réel avait une wwwURL et les URI de redirection autorisés dans la console développeur de Google avaient une non-wwwURL. Par conséquent, il y avait un décalage dans l'URI de redirection. Je l'ai résolu en mettant Authorized Redirect URIsà jour dans Google Developer Console vers wwwURL.

D'autres incompatibilités d'URI courantes sont:

• Utilisation http://dans les URI de redirection autorisés et https://comme URL réelle, ou vice-versa
• Utilisation de la barre oblique de fin ( http://example.com/) dans les URI de redirection autorisés et non de la barre oblique de fin ( http://example.com) comme URL réelle, ou vice-versa

Voici les captures d'écran étape par étape de la console développeur de Google afin qu'il soit utile pour ceux qui ont du mal à localiser la page de la console développeur de mettre à jour les URI de redirection.

1. Accédez à https://console.developers.google.com

2. Sélectionnez votre projet

3. Cliquez sur l'icône du menu

4. Cliquez sur le API Managermenu

5. Cliquez sur le Credentialsmenu. Et sous OAuth 2.0 Client IDs, vous trouverez le nom de votre client. Dans mon cas, ça l'est Web Client 1. Cliquez dessus et une fenêtre apparaîtra où vous pouvez modifier l' origine Javascript autorisée et les URI de redirection autorisés .

Voici un article Google sur la création d'ID de projet et de client .

Si vous utilisez le bouton javascript Google+ , vous devez utiliser à la postmessageplace de l'URI réel. Il m'a fallu presque toute la journée pour comprendre cela, car les documents de Google ne le précisent pas clairement pour une raison quelconque.

Dans tout flux où vous avez récupéré un code d'autorisation côté client, tel que l' GoogleAuth.grantOfflineAccess()API , et maintenant vous souhaitez transmettre le code à votre serveur, le racheter et stocker les jetons d'accès et d'actualisation, vous devez alors utiliser la chaîne littérale postmessageau lieu de redirect_uri.

Par exemple, en s'appuyant sur l'extrait de code dans la documentation 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 seule documentation Google à mentionner postmessageest cet ancien document de connexion à Google+ . Voici une capture d'écran et un lien d'archivage depuis la fermeture de G + et ce lien disparaîtra probablement:

Il est absolument impardonnable que la page de documentation pour l'accès hors ligne ne le mentionne pas. #FacePalm

Pour mon application web j'ai corrigé mon erreur en écrivant

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

Assurez-vous de vérifier le protocole "http: //" ou "https: //" en tant que protocole de vérification Google également. Mieux vaut ajouter les deux URL dans la liste.

Cela semble assez étrange et ennuyeux qu'aucune solution "unique" n'existe. pour moi, http: // localhost: 8000 n'a pas fonctionné mais http: // localhost: 8000 / a fonctionné.

Lorsque vous enregistrez votre application sur https://code.google.com/apis/console et créez un ID client, vous avez la possibilité de spécifier un ou plusieurs URI de redirection. La valeur du redirect_uriparamètre sur votre URI d'authentification doit correspondre exactement à l'un d'eux.

Cette réponse est la même que cette réponse de Mike , et la réponse de Jeff , les deux ensembles redirect_urià postmessagecôté client. Je veux ajouter plus sur le côté serveur, ainsi que sur les circonstances particulières s'appliquant à cette configuration.

Tech Stack

Backend

• Python 3.6
• Django 1.11
• Django REST Framework 3.9 : serveur en tant qu'API, pas de modèle de rendu, ne faisant pas grand-chose ailleurs.
• Django REST Framework JWT 1.11
• Django REST Social Auth <2.1

L'extrémité avant

• React : 16.8.3, create-react-appversion 2.1.5
• react-google-login : 5.0.2

Le flux "Code" (spécialement pour Google OAuth2)

Résumé: Réagissez -> demandez le "code" d'authentification sociale -> demandez le jeton jwt pour acquérir le statut de "connexion" en termes de votre propre serveur / base de données backend.

1. Frontend (React) utilise un "bouton de connexion Google" avec responseType="code"pour obtenir un code d'autorisation. (ce n'est pas un jeton, pas un jeton d'accès!)
   • Le bouton de connexion Google provient de celui react-google-loginmentionné ci-dessus.
   • Cliquez sur le bouton pour faire apparaître une fenêtre contextuelle permettant à l'utilisateur de sélectionner un compte. Une fois que l'utilisateur en a sélectionné un et que la fenêtre se ferme, vous obtiendrez le code de la fonction de rappel du bouton.
2. Le frontend l'envoie au point de terminaison JWT du serveur backend.
   • Demande POST, avec { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
3. Pour mon serveur Django, j'utilise Django REST Framework JWT + Django REST Social Auth. Django reçoit le code du frontend, vérifiez-le auprès du service Google (fait pour vous). Une fois vérifié, il renverra le JWT (le jeton) au frontend. Frontend peut désormais récolter le jeton et le stocker quelque part.
   • Tous REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_ORIGINet REST_SOCIAL_OAUTH_REDIRECT_URIdans Django ne settings.pysont pas nécessaires . (Ce sont des constantes utilisées par Django REST Social Auth) En bref, vous n'avez rien à configurer pour rediriger l'url dans Django . Le "redirect_uri": "postmessage"frontend in React suffit. Cela a du sens car le travail d'authentification sociale que vous avez à faire de votre côté est toute demande POST de style Ajax en frontend, ne soumettant aucun formulaire, donc en fait aucune redirection ne se produit par défaut. C'est pourquoi l'URL de redirection devient inutile si vous utilisez le flux code + JWT, et le paramètre d'URL de redirection côté serveur ne prend aucun effet.
4. Django REST Social Auth gère la création de compte. Cela signifie qu'il vérifiera l'adresse e-mail / le prénom de votre compte Google et verra s'il correspond à un compte de la base de données. Sinon, il en créera un pour vous, en utilisant l'e-mail et le prénom exact. Mais, le nom d'utilisateur ressemblera à youremailprefix717e248c5b924d60votre e-mail youremailprefix@example.com. Il ajoute une chaîne aléatoire pour créer un nom d'utilisateur unique. C'est le comportement par défaut, je pense que vous pouvez le personnaliser et n'hésitez pas à fouiller dans leur documentation.
5. Le frontend stocke ce jeton et quand il doit exécuter CRUD sur le serveur backend, en particulier créer / supprimer / mettre à jour, si vous attachez le jeton dans votre en- Authorizationtête et envoyez une demande au backend, le backend Django reconnaîtra maintenant cela comme une connexion, c'est-à-dire authentifié utilisateur. Bien sûr, si votre token expire, vous devez le rafraîchir en faisant une autre demande.

Oh mon Dieu, j'ai passé plus de 6 heures et j'ai finalement compris! Je crois que c'est la première fois que je vois cette postmessagechose. Quiconque travaille sur une Django + DRF + JWT + Social Auth + Reactcombinaison va définitivement s'y planter. Je ne peux pas croire qu'aucun des articles ne le mentionne, sauf les réponses ici. Mais j'espère vraiment que ce message peut vous faire gagner beaucoup de temps si vous utilisez la pile Django + React.

2015juillet15 - la connexion qui fonctionnait la semaine dernière avec ce script lors de la connexion

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

a cessé de fonctionner et a commencé à provoquer l'erreur 400 avec Error: redirect_uri_mismatch

et dans la section DÉTAILS: redirect_uri=storagerelay://...

je l'ai résolu en changeant pour:

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

Liste de contrôle:

• httpou https?
• &ou &?
• barre oblique ( /) ou ouverte ?
• (CMD/CTRL)+F, recherchez la correspondance exacte dans la page d'informations d'identification. S'il n'est pas trouvé, recherchez celui qui manque.
• Attendez que google le rafraîchisse. Peut se produire dans chaque demi-heure si vous changez fréquemment ou s'il reste dans la piscine. Pour mon cas, il a fallu près d'une demi-heure pour prendre effet.

Dans mon cas, mon type de demande d'informations d'identification est "Autre". Je ne trouve donc pas Authorized redirect URIssur la page d'informations d'identification. Il apparaît dans Type d'application: "Application Web". Mais vous pouvez cliquer sur le Download JSONbouton pour obtenir le client_secret.jsonfichier.

Ouvrez le fichier JSON, et vous pouvez trouver le paramètre comme ceci: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. J'ai choisi d'utiliser http: // localhost et cela fonctionne bien pour moi.

L'URL de redirection est sensible à la casse.

Dans mon cas, j'ai ajouté les deux: http: // localhost: 5023 / AuthCallback / IndexAsync http: // localhost: 5023 / authcallback / indexasync

Aucune des solutions ci-dessus n'a fonctionné pour moi. ci-dessous

changer les URL de redirection autorisées en - https: // localhost: 44377 / signin-google

J'espère que cela aide quelqu'un.

méfiez-vous du supplément /à la fin de l'url http://localhost:8000est différent dehttp://localhost:8000/

Utilisateurs de Rails (à partir des documents omniauth-google-oauth2 ):

Correction de l'incompatibilité de protocole pour redirect_uri dans Rails

Définissez simplement le full_host dans OmniAuth en fonction de Rails.env.

# config / initializers / omniauth.rb

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

N'OUBLIEZ PAS: N'incluez pas le "/" de fin

Si vous utilisez ce didacticiel: https://developers.google.com/identity/sign-in/web/server-side-flow, vous devez utiliser "postmessage".

Dans GO, cela a résolu le problème:

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

pour moi, c'était parce que dans la liste «URI de redirection autorisée», j'ai incorrectement mis à la https://developers.google.com/oauthplayground/place de https://developers.google.com/oauthplayground(sans /à la fin).

Permettez-moi de compléter la réponse de @ Bazyl: dans le message que j'ai reçu, ils ont mentionné l'URI "http://localhost:8080/" (qui, bien sûr, semble être une configuration interne de Google). J'ai changé l'URI autorisé pour celui-ci, "http://localhost:8080/"et le message n'apparaissait plus ... Et la vidéo a été téléchargée ... La documentation APIS est TRÈS boiteuse ... Chaque fois que j'ai quelque chose qui fonctionne avec Google Apis, je simplement se sentir "chanceux", mais il y a un manque de bonne documentation à ce sujet .... :( Oui, je l'ai fait fonctionner, mais je ne comprends pas encore pourquoi il a échoué, ni pourquoi cela a fonctionné ... Il n'y en avait qu'un endroit pour confirmer l'URI sur le Web, et il a été copié dans le client_secrets.json ... Je ne reçois pas s'il y a un TROISIÈME endroit où l'on devrait écrire le même URI ... Je ne trouve pas seulement la documentation mais aussi le Conception graphique de Google '

Quiconque a du mal à trouver où définir les URL de redirection dans la nouvelle console: API et authentification -> Informations d'identification -> ID client OAuth 2.0 -> Cliquez sur le lien pour trouver toutes vos URL de redirection

Je devais créer un nouvel ID client sous API et services -> Informations d'identification -> Créer des informations d'identification -> OAuth -> Autre

Ensuite, j'ai téléchargé et utilisé le client_secret.json avec mon programme de ligne de commande qui télécharge sur mon compte youtube. J'essayais d'utiliser un ID client OAuth Web App qui me donnait l'erreur URI de redirection dans le navigateur.

Essayez de faire ces vérifications:

1. ID de bundle dans la console et dans votre application. Je préfère définir le Bundle ID de l'application comme ceci "org.peredovik. $ {PRODUCT_NAME: rfc1034identifier}"
2. Vérifiez si vous avez ajouté des types d'URL dans l'onglet Info, saisissez simplement votre ID de bundle dans Identifier et URL Schemes, rôle défini sur Editor
3. Dans la console sur cloud.google.com "APIs & auth" -> "Écran de consentement", remplissez le formulaire concernant votre application. "Nom du produit" est un champ obligatoire.

Prendre plaisir :)

Dans mon cas, j'ai dû vérifier le type d'ID client pour les applications Web / applications installées.

applications installées: http: // localhost [URI de redirection] Dans ce cas, localhost fonctionne simplement

applications Web: vous avez besoin d'un nom de domaine valide [URI de redirection:]

Ce que vous devez faire, c'est retourner dans votre console développeur et aller dans APIs & Auth> Écran de consentement et le remplir. Plus précisément, le nom du produit.

N'oubliez pas d'inclure le chemin après votre domaine et votre ip. Dans mon cas, j'ai oublié:

/ oauth2callback

J'ai eu deux URI de demande dans la console, http: // xxxxx / client / api / spreadsheet / authredirect et http: // localhost .

J'ai essayé toutes les meilleures réponses à cette question et confirmé qu'aucun d'entre eux n'était mon problème.

J'ai supprimé localhost de la console, mis à jour mon client_secret.json dans mon projet et l'erreur de non-concordance a disparu.

J'ai eu le même problème avec la connexion à Google, j'étais sur le point de me tirer les cheveux !!! J'avais correctement entré mes rappels dans le panneau Google Credential sur la console développeur de Google, voici mes URL de redirection:

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

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

https://www.example.com/oauth2callback

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

tout semble bien non? mais il n'a toujours pas de travail jusqu'à ce que j'ajouté un plus magique Url j'ai ajouté signin-google url (qui est rappel par défaut de Google) sans www et problème résolu.

en tenir compte (en fonction de votre domaine) vous pouvez ou non avoir besoin d'ajouter à la fois avec et sans URL www

J'ai l'application frontend et l'api backend.

À partir de mon serveur principal, je testais en appuyant sur Google api et je faisais face à cette erreur. Pendant tout mon temps, je me demandais pourquoi devrais-je devoir donner redirect_uricar ce n'est que le backend, pour le front, cela a du sens.

Ce que je faisais était différent redirect_uri(bien que valide) du serveur (en supposant que ce soit juste un espace réservé, il n'a qu'à être enregistré sur google) mais mon URL frontale qui a créé le code du jeton était différente. Donc, lorsque je passais ce code dans mes tests côté serveur (pour lesquels redirect-uri était différent), j'étais confronté à cette erreur.

Alors ne faites pas cette erreur. Assurez-vous que votre frontend redirect_uriest le même que celui de votre serveur car Google l'utilise pour valider l'authenticité.

Voici les raisons de l'erreur: le problème de redirect_uri_mismatch se produit:

1. Redirigez le champ URL vide dans votre projet Google.
2. L'URL de redirection ne correspond pas à votre site
3. Important! Cela ne fonctionnera qu'avec un domaine de travail comme example.com, book.com, etc. (ne fonctionne pas avec l'hôte local ou l'URL AWS LB)

Recommandé d'utiliser l'URL du domaine

L'astuce consiste à saisir l'URL de redirection appropriée au moment de la création de l'ID. J'ai trouvé que la mise à jour de l'URL de redirection une fois l'ID créé via un "Modifier" ne fait tout simplement pas le travail. Ce qui a également fonctionné pour moi, c'est de dupliquer l'intégralité du dossier `` fournisseur '' et de le copier au même emplacement où se trouve le fichier `` oauth '' (jusqu'à ce que vous ayez réussi à générer le jeton et que vous puissiez ensuite supprimer le dossier `` fournisseur '' en double). En effet, essayer de pointer vers le dossier du fournisseur via «../vendor/autoload» n'a pas fonctionné pour moi.

Donc, supprimez votre ID OAuth client problématique existant et essayez cette approche, cela fonctionnera.