Autorisation Google OAuth 2 - Erreur: redirect_uri_mismatch
Sur le site Web https://code.google.com/apis/console j'ai enregistré mon application, configuré ID client: et Client Secret sur mon application et essayé de me connecter. avec Google . Malheureusement, le message d'erreur suivant s'affiche:
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 réparer? .__ J'utilise la gem 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 recherchez sous API Access. Vous devriez voir votre client ID & client secret ici, ainsi qu'une liste des URI de redirection. Si l'URI souhaité ne figure pas dans la liste, cliquez sur Éditer 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 la modification présente peuvent prendre un certain temps. En général, quelques minutes seulement mais parfois, cela semble plus long.
Dans mon cas, il s’agissait des URL www et non-www. L'URL du site réel était www et l'URI de redirection autorisée dans la console pour les développeurs de Google avait l'URL non-www. Par conséquent, il y avait une discordance dans l'URI de redirection. Je l'ai résolu en mettant à jour Authorized Redirect URIs dans la console Google Developer Console avec l'URL www.
Les autres incompatibilités d'URI courantes sont:
- Utilisation de
http://dans les URI de redirection autorisés et dehttps://en tant qu'URL réelle, ou inversement - Utilisation de la barre oblique finale (
http://example.com/) dans les URI de redirection autorisée et de ne pas utiliser la barre oblique finale (http://example.com) comme URL réelle, ou inversement
Voici les captures d'écran pas à pas de la console pour les développeurs Google. Il serait donc utile pour ceux qui ont du mal à localiser la page de la console du développeur pour mettre à jour les URI de redirection.
Accédez à https://console.developers.google.com
Sélectionnez votre projet
- Cliquez sur l'icône du menu
- Cliquez sur le menu
API Manager
- Cliquez sur le menu
Credentials. Et sousOAuth 2.0 Client IDs, vous trouverez votre nom de client. Dans mon cas, c'estWeb Client 1. Cliquez dessus et une fenêtre contextuelle apparaîtra dans laquelle vous pourrez éditer URI de redirection JavaScript autorisé et Autorisé.
Voici un article de Google sur la création d'un projet et d'un ID client .
Si vous utilisez Bouton javascript Google+ , vous devez alors utiliser postmessage à la place de l'URI réel. Cela m'a pris presque toute la journée pour comprendre cela, car les documents de Google ne l'indiquent pas clairement pour une raison quelconque.
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: //" comme le vérifie également le protocole de Google.
Dans tous les flux où vous avez récupéré un code d'autorisation côté client, tel que l'API GoogleAuth.grantOfflineAccess(), vous souhaitez maintenant transmettre le code à votre serveur, l'utiliser Pour accéder aux jetons et les actualiser, vous devez utiliser la chaîne littérale postmessage au lieu de redirect_uri.
Par exemple, en vous basant sur l'extrait de code dans Ruby doc :
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 mentionnant même la variable postmessage est celle-ci ancien document de connexion Google+ . Il est absolument impardonnable que la page doc pour Offline Access ne mentionne pas cela. #FacePalm
Cela semble assez étrange et ennuyeux qu’aucune «une» solution 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 Make un ID client, vous avez la possibilité de spécifier une ou plusieurs URL de redirection La valeur du paramètre redirect_uri sur votre URI d'authentification doit correspondre exactement à l'un d'entre eux.
Liste de contrôle:
httpouhttps?&ou&?- slash de fin (
/) ou ouvrir? (CMD/CTRL)+F, recherchez la correspondance exacte dans la page d'informations d'identification. Si Non trouvé, cherchez celui qui manque.- Attendez que Google l'actualise. Cela peut arriver toutes les demi-heures si vous changez fréquemment ou si vous restez dans la piscine. Pour mon cas, il fallait presque une demi-heure pour prendre effet.
2015July15 - 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 provoqué l'erreur 400 avec Error: redirect_uri_mismatch
et dans la section DETAILS: redirect_uri=storagerelay://...
je l'ai résolu en changeant pour:
<script src="https://apis.google.com/js/client:platform.js?onload=startApp"></script>
Aucune des solutions ci-dessus n'a fonctionné pour moi. ci-dessous a fait
changer les URL de redirection autorisées vers - https: // localhost: 44377/signin-google
J'espère que ça aide quelqu'un.
Cette réponse est identique à la réponse de Mike , et la réponse de Jeff , les deux définissent redirect_uri à postmessage du côté client. Je veux ajouter plus d'informations sur le côté serveur, ainsi que sur les circonstances particulières s'appliquant à cette configuration.
Pile technologique
Backend
- Python 3.6
- Django 1.11
- Django REST Framework 3.9 : serveur en tant qu'API, pas de modèle de rendu, ne fait pas grand chose ailleurs.
- Django REST Framework JWT 1.11
- Django REST Auth Social <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écifiquement pour Google OAuth2)
Résumé: Réagissez -> demandez un code d'authentification social -> demandez à un jeton jwt d'acquérir le statut de "connexion" en fonction de votre propre serveur/base de données.
- 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 du
react-google-loginmentionné ci-dessus. - Cliquez sur le bouton pour afficher 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 s'est fermée, vous obtiendrez le code de la fonction de rappel du bouton.
- Le bouton de connexion Google provient du
- Frontend envoie cette information au noeud final JWT du serveur principal.
- Requête POST, avec
{ "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
- Requête POST, avec
- Pour mon serveur Django, j'utilise Django REST Framework JWT + Django REST Auth Social. Django reçoit le code de frontend, vérifiez-le avec le service de Google (fait pour vous). Une fois vérifié, il enverra le JWT (le jeton) à l’interface utilisateur. Frontend peut maintenant récolter le jeton et le stocker quelque part.
- Tous les
REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI,REST_SOCIAL_DOMAIN_FROM_OriginetREST_SOCIAL_OAUTH_REDIRECT_URIdans lesettings.pyde Django sont inutiles . (Ce sont des constantes utilisées par Django REST Auth Social) En bref, vous n'avez pas besoin de configurer quoi que ce soit pour rediriger l'URL dans Django . Le"redirect_uri": "postmessage"dans React Frontend suffit. Cela a du sens, car le travail d’authentification sociale que vous devez faire de votre côté correspond à toute requête Ajax POST de style Ajax en front-end, sans soumission de formulaire, ce qui signifie qu’aucune redirection n’a lieu 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.
- Tous les
- Django REST _ Social Auth gère la création de compte. Cela signifie qu'il vérifiera l'adresse e-mail/le nom de famille du compte Google et vérifiera s'il correspond à un compte de la base de données. Sinon, il en créera un pour vous, en utilisant l'adresse e-mail exacte et le prénom. Mais le nom d'utilisateur sera quelque chose comme
youremailprefix717e248c5b924d60si votre email est[email protected]. 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 à plonger dans leur documentation. - Le frontend stocke ce jeton et quand il doit exécuter CRUD sur le serveur principal, en particulier créer/supprimer/mettre à jour, si vous attachez le jeton dans votre en-tête
Authorizationet envoyez une demande au backend, le backend Django le reconnaîtra maintenant, c'est-à-dire Utilisateur authentifié. Bien sûr, si votre jeton expire, vous devez l'actualiser en effectuant une autre demande.
Oh mon Dieu, j'ai passé plus de 6 heures et j'ai finalement réussi! Je crois que c’est la première fois que je vois cette chose postmessage. Quiconque travaille sur une combinaison de Django + DRF + JWT + Social Auth + React va définitivement tomber en panne. Je ne peux pas croire qu'aucun article de cet article ne mentionne cela, à l'exception des réponses fournies ici. Mais j'espère vraiment que cet article pourra vous faire gagner beaucoup de temps si vous utilisez la pile Django + React.
Utilisateurs Rails (à partir de omniauth-google-oauth2 docs):
Résolution d'incompatibilité de protocole pour redirect_uri dans Rails
Il suffit de définir le full_Host dans OmniAuth en fonction du fichier 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 "/" final
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,
}
méfiez-vous des / à la fin de l'URL http://localhost:8000 est différent de http://localhost:8000/
Dans mon cas, le type de mes informations d'identification est "Autre". Donc, je ne trouve pas Authorized redirect URIs dans la page des informations d'identification. Il semble que dans le type d'application: "application Web". Mais vous pouvez cliquer sur le bouton Download JSON pour obtenir le fichier client_secret.json . 
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 très bien pour moi.
pour moi, c’est parce que dans la liste 'URI de redirection autorisée', j'ai incorrectement mis https://developers.google.com/oauthplayground/ au lieu de https://developers.google.com/oauthplayground (sans / à la fin).
Toute personne qui a du mal à trouver où définir les URL de redirection dans la nouvelle console: API et authentifications -> Informations d'identification -> ID clients OAuth 2.0 -> Cliquez sur le lien pour trouver toutes vos URL de redirection
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 google interne). J'ai changé l'URI autorisé pour celui-là, "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 quelque chose fonctionne avec Google apis, je me sens tout simplement "chanceux", mais il y a un manque de bonne documentation à ce sujet .... :( Oui, ça marche, mais je ne comprends pas encore pourquoi ça a échoué, ni pourquoi ça a marché ... Il n'y avait qu'UN SEUL endroit pour confirmer l'URI sur le Web, et cela a été copié dans le fichier client_secrets.json ... Je ne comprends pas s'il y a un TROISIÈME endroit où l'on devrait écrire le même URI ... la documentation mais aussi la conception graphique de l'api de Google assez boiteux ...
J'avais besoin de créer un nouvel ID client sous API et services -> Informations d'identification -> Créer les 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 est chargé sur mon compte youtube. J'essayais d'utiliser un ID client Web App OAuth qui me donnait l'erreur de redirection URI dans le navigateur.
N'oubliez pas d'inclure le chemin après votre domaine et votre adresse IP. Dans mon cas, j'ai oublié:
/ oauth2callback
J'avais deux URI de requête dans la console, http: // xxxxx/client/api/spreadsheet/authredirect et http: // localhost .
J'ai essayé toutes les principales réponses à cette question et j'ai confirmé qu'aucune d'entre elles n'était mon problème.
J'ai supprimé localhost de la console, mis à jour mon client_secret.json dans mon projet et l'erreur d'incompatibilité a disparu.
Ce que vous devez faire est de revenir à votre console de développeur, accédez à API & Auth> Écran de consentement et complétez-le. Plus précisément, le nom du produit.
Essayez de faire ces vérifications:
- ID de lot dans la console et dans votre application. Je préfère définir l'ID d'ensemble de l'application comme ceci: "org.peredovik. $ {PRODUCT_NAME: rfc1034identifier}"
- Vérifiez si vous avez ajouté des types d'URL à l'onglet Info, saisissez simplement votre ID d'ensemble dans les modèles d'identificateurs et d'URL, rôle défini sur Editeur.
- Dans la console sur cloud.google.com "API et authentification" -> "Écran de consentement", remplissez le formulaire relatif à votre application. "Nom du produit" est un champ obligatoire.
Prendre plaisir :)
Dans mon cas, je devais vérifier le type d'identifiant client pour les applications Web/les applications installées.
applications installées: http: // localhost [Redirect URIs] Dans ce cas, localhost fonctionne simplement
applications Web: vous avez besoin d'un nom de domaine valide [URL de redirection:]
J'avais le même problème à autoriser dans l'application Reactjs sur mon ordinateur local avec le port 3000.
J'ai ajouté lvh.me dans les domaines autorisés et http://lvh.me:3000 pour Authorisée autorisée et URL de redirection autorisée, comme indiqué dans les images suivantes.
Remarque: vous pouvez ajouter plusieurs sites pour les domaines vérifiés. i-e pour votre machine locale, votre environnement intermédiaire ou d'autres environnements
J'ai eu ce problème en utilisant Meteor et Ngrok, alors que j'essayais de me connecter à Google. J'ai placé l'URL Ngrok dans la console du développeur Google sous forme d'URL de redirection, puis je suis allé à la page URL de Ngrok. Le fait est que je n’ai pas utilisé ROOT_URL de Meteor lors de l’exécution de l’application, donc toute redirection irait à localhost:3000 à partir de l’URL de Ngrok. Il suffit de le corriger en ajoutant l'URL de Ngrok sous la forme ROOT_URL dans la configuration de Meteor ou en l'exportant avant d'exécuter l'application sur le terminal, comme suit: export ROOT_URL=https://my_ngrok_url
Pour que cela fonctionne sur localhost et si vous utilisez un serveur Web, fournissez
Authorized JavaScript origins (Client ID for web appication)
e.g. http://localhost:4200
L'astuce consiste à saisir la bonne URL de redirection au moment de la création de l'ID. J'ai constaté que la mise à jour de l'URL de redirection une fois que l'ID avait été créé via un "Edition" ne suffisait tout simplement pas. Ce qui a également fonctionné pour moi est de dupliquer le dossier "fournisseur" dans son intégralité et de le copier au même emplacement que le fichier "oauth" (jusqu'à ce que vous ayez généré 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.
Supprimez donc votre ID client OAuth problématique et essayez cette approche, elle fonctionnera.
Vous trouverez ci-dessous les raisons d'erreur: un problème de redirect_uri_mismatch se produit:
- Champ URL de redirection vide dans votre projet Google.
- URL de redirection ne correspond pas à votre site
- Important! Cela fonctionnera uniquement avec des domaines tels que 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
J'ai application frontend et backend api.
À partir de mon serveur principal, je testais en tapant Google Api et je faisais face à cette erreur. Pendant tout mon temps, je me demandais pourquoi je devrais donner redirect_uri car il ne s'agit que du backend, car cela a du sens pour frontend.
Ce que je faisais, c'était de donner redirect_uri différent (bien que valide) du serveur (en supposant qu'il ne s'agisse que d'un espace réservé, il suffit simplement de s'enregistrer sur Google), mais mon URL frontale ayant créé le code de jeton était différente. Ainsi, lorsque je transmettais ce code lors de mes tests côté serveur (pour lesquels redirect-uri était différent), je faisais face à cette erreur.
Alors ne faites pas cette erreur. Assurez-vous que votre redirect_uri frontal est identique à celui de votre serveur, car Google l'utilise pour valider l'authenticité.