Google OAuth 2-Autorisierung - Fehler: redirect_uri_mismatch

In meinem Fall war es www und non-www URL. Die tatsächliche Site hatte eine www-URL und die Authorized Redirect-URIs in der Google Developer Console hatten eine non-www-URL. Daher gab es Unstimmigkeiten bei der Umleitung der URI. Ich habe das Problem gelöst, indem Sie Authorized Redirect URIs in der Google Developer Console auf www URL aktualisiert haben.

Andere häufige URI-Unstimmigkeiten sind:

• Verwenden von http:// in autorisierten Umleitungs-URIs und https:// als tatsächliche URL oder umgekehrt
• Verwenden Sie den nachstehenden Schrägstrich (http://example.com/) in autorisierten Umleitungs-URIs und nicht den nachstehenden Schrägstrich (http://example.com) als tatsächliche URL oder umgekehrt

Hier sind die Schritt-für-Schritt-Screenshots der Google Developer Console, so dass es für diejenigen hilfreich sein könnte, die Schwierigkeiten haben, die Seite der Entwicklerkonsole zu finden, um URIs für die Weiterleitung zu aktualisieren.

1. Gehen Sie zu https://console.developers.google.com

2. Wählen Sie Ihr Projekt aus

3. Klicken Sie auf das Menüsymbol

4. Klicken Sie auf API Manager Menü

5. Klicken Sie auf das Menü Credentials. Unter OAuth 2.0 Client IDs finden Sie Ihren Kundennamen. In meinem Fall ist es Web Client 1. Klicken Sie darauf, und es erscheint ein Popup, in dem Sie Authorized Javascript Origin und Authorized Umleitungs-URIs bearbeiten können.

Hier ist ein Google-Artikel zum Erstellen von Projekt- und Kundennummer . 

Wenn Sie die JavaScript-Schaltfläche Google+ verwenden, müssen Sie anstelle der eigentlichen URI postmessage verwenden. Ich habe fast den ganzen Tag gebraucht, um das herauszufinden, da die Dokumente von Google aus irgendeinem Grund nicht klar angegeben werden.

Für meine Webanwendung habe ich meinen Fehler schriftlich korrigiert

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

Stellen Sie sicher, dass Sie das Protokoll "http: //" oder "https: //" als Google-Prüfprotokoll überprüfen Fügen Sie beide URLs der Liste hinzu.

In einem Fluss, in dem Sie auf der Clientseite einen Authorization-Code abgerufen haben, z. B. - GoogleAuth.grantOfflineAccess()-API. Nun möchten Sie den Code an Ihren Server übergeben, ihn einlösen und speichern Wenn Sie auf Token zugreifen und diese aktualisieren, müssen Sie anstelle des Weiterleitungszeichens die Literalzeichenfolge postmessage verwenden.

Bauen Sie beispielsweise das Snippet im Ruby-Dokument auf:

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"}

Die einzige Google-Dokumentation, die sogar postmessage erwähnt, ist dieses alte Google+ Anmelde-Dokument . Es ist absolut unverzeihlich, dass die doc-Seite für den Offline-Zugriff dies nicht erwähnt. #FacePalm

Dies erscheint ziemlich seltsam und ärgerlich, dass es keine "eine" Lösung gibt. für mich http: // localhost: 8000 hat nicht geklappt, aber http: // localhost: 8000/ hat geklappt.

Wenn Sie Ihre App unter https://code.google.com/apis/console - registrieren und eine Client-ID erstellen, haben Sie die Möglichkeit, eine oder mehrere Weiterleitungs-URIs anzugeben. Der Wert des Parameters redirect_uri in Ihrer Auth-URI muss Genau mit einem von ihnen übereinstimmen.

Checkliste:

• http oder https?
• & oder &?
• nachstehender Schrägstrich (/) oder offener ?
• (CMD/CTRL)+F, suchen Sie auf der Seite mit den Anmeldeinformationen nach der genauen Übereinstimmung. Wenn Nicht gefunden wurde, suchen Sie nach dem fehlenden.
• Warten Sie, bis Google es aktualisiert hat. Kann in jeder halben Stunde passieren, wenn Sie Häufig wechseln oder im Pool bleiben. Für meinen Fall war es fast eine halbe Stunde, um wirksam zu werden.

2015Juli15 - die Anmeldung, die letzte Woche mit diesem Skript beim Anmelden gearbeitet hat

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

funktionierte nicht mehr und verursachte Fehler 400 mit Error: redirect_uri_mismatch

und im Abschnitt DETAILS: redirect_uri=storagerelay://...

ich löste es, indem ich wechselte zu:

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

Bei der Weiterleitungs-URL wird die Groß- und Kleinschreibung beachtet.

In meinem Fall habe ich beide hinzugefügt: http: // localhost: 5023/AuthCallback/IndexAsynchttp: // localhost: 5023/authcallback/indexasync

Keine der oben genannten Lösungen funktionierte für mich. unten tat es

Ändern Sie autorisierte Weiterleitungs-URLs in - https: // localhost: 44377/signin-google

Hoffe das hilft jemandem.

Diese Antwort ist dieselbe wie diese Mikes Antwort , und Jeffs Antwort , beide setzen redirect_uri auf postmessage auf Client-Seite. Ich möchte mehr über die Serverseite und die besonderen Umstände hinzufügen, die für diese Konfiguration gelten.

Tech Stack

Backend

• Python 3.6
• Django 1.11
• Django REST Framework 3.9 : Server als API, keine Vorlage rendern, nicht viel anderswo tun.
• Django REST Framework JWT 1.11
• Django REST Social Auth <2.1

Vorderes Ende

• Reagieren : 16.8.3, create-react-app version 2.1.5
• google-login reagieren : 5.0.2

Der "Code" -Fluss (speziell für Google OAuth2)

Zusammenfassung: Reagieren Sie -> fordern Sie den "Code" der sozialen Authentifizierung an -> fordern Sie das JWT-Token an, den Anmeldestatus für Ihren eigenen Back-End-Server/Ihre eigene Datenbank zu erhalten.

1. Frontend (React) verwendet eine "Google-Anmeldeschaltfläche" mit responseType="code", um einen Autorisierungscode zu erhalten. (Es ist kein Token, kein Zugriffstoken!)
   • Die Google-Anmeldeschaltfläche stammt aus dem oben genannten react-google-login.
   • Klicken Sie auf die Schaltfläche, um ein Popup-Fenster zu öffnen, in dem der Benutzer ein Konto auswählen kann. Nachdem der Benutzer eine ausgewählt und das Fenster geschlossen hat, erhalten Sie den Code von der Rückruffunktion der Schaltfläche.
2. Frontend Sende dies an den JWT-Endpunkt des Backend-Servers.
   • POST-Anfrage mit{ "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
3. Für meinen Django-Server verwende ich Django REST Framework JWT + Django REST Social Auth. Django erhält den Code vom Frontend und überprüft ihn beim Google-Dienst (für Sie erledigt). Nach der Überprüfung wird das JWT (das Token) zurück an das Frontend gesendet. Das Frontend kann den Token nun sammeln und irgendwo aufbewahren.
   • Alle REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_Origin und REST_SOCIAL_OAUTH_REDIRECT_URI in Djangos settings.py sind unnötig . (Dies sind Konstanten, die von Django REST Social Auth verwendet werden.) Kurz gesagt, Sie müssen in Django nichts im Zusammenhang mit der Weiterleitungs-URL einrichten . Der "redirect_uri": "postmessage" im React Frontend reicht aus. Dies ist sinnvoll, da die soziale Authentifizierungsarbeit, die Sie auf Ihrer Seite erledigen müssen, nur eine Ajax-artige POST -Anforderung im Frontend ist, die keinerlei Form sendet, sodass standardmäßig keine Umleitung erfolgt. Aus diesem Grund wird die Umleitungs-URL unbrauchbar, wenn Sie den Code + JWT-Fluss verwenden und die serverseitige Umleitungs-URL-Einstellung keine Auswirkung hat.
4. Der Django REST Social Auth verwaltet die Kontoerstellung. Dies bedeutet, dass die E-Mail-Adresse/der Nachname des Google-Kontos überprüft wird und geprüft wird, ob sie mit einem Konto in der Datenbank übereinstimmt. Andernfalls wird eine E-Mail mit der genauen E-Mail-Adresse und dem Vornamen erstellt. Der Benutzername lautet jedoch youremailprefix717e248c5b924d60, wenn Ihre E-Mail-Adresse [email protected] lautet. Es wird eine zufällige Zeichenfolge angehängt, um einen eindeutigen Benutzernamen zu erstellen. Dies ist das Standardverhalten. Ich glaube, Sie können es anpassen und in der Dokumentation nachlesen.
5. Das Frontend speichert dieses Token und wenn es CRUD auf dem Backend-Server ausführen muss, insbesondere Erstellen/Löschen/Aktualisieren, wenn Sie das Token in Ihrem Authorization -Header anhängen und eine Anfrage an das Backend senden, erkennt das Django-Backend dies nun als Login, dh authentifizierter Nutzer. Wenn Ihr Token abläuft, müssen Sie es natürlich aktualisieren, indem Sie eine weitere Anfrage stellen.

Oh du meine Güte, ich habe mehr als 6 Stunden damit verbracht und endlich alles richtig gemacht! Ich glaube, dies ist das erste Mal, dass ich dieses postmessage Ding gesehen habe. Jeder, der an einer Django + DRF + JWT + Social Auth + React-Kombination arbeitet, wird definitiv darauf stoßen. Ich kann nicht glauben, dass keiner der Artikel dies erwähnt, außer Antworten hier. Aber ich hoffe wirklich, dass dieser Beitrag Ihnen jede Menge Zeit sparen kann, wenn Sie den Django + React-Stapel verwenden.

Rails-Benutzer (von omniauth-google-oauth2 docs): 

Fixing Protocol Mismatch für redirect_uri in Rails

Setzen Sie einfach den full_Host in OmniAuth basierend auf den Rails.env.

# config/initializers/omniauth.rb

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

ANMERKUNG: Fügen Sie nicht das abschließende "/" ein.

Wenn Sie dieses Tutorial verwenden: https://developers.google.com/identity/sign-in/web/server-side-flow , sollten Sie "postmessage" verwenden.

In GO wurde das Problem behoben:

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

beachten Sie den zusätzlichen / am Ende der URL http://localhost:8000 unterscheidet sich von http://localhost:8000/

In meinem Fall lautet mein Anmeldeinformationstyp "Sonstige". Daher kann ich Authorized redirect URIs nicht auf der Seite mit den Anmeldeinformationen finden. Es scheint in Anwendungstyp zu erscheinen: "Webanwendung". Sie können jedoch auf die Schaltfläche Download JSON klicken, um die client_secret.json-Datei zu erhalten .  

Öffnen Sie die Json-Datei, und Sie können den Parameter wie folgt finden: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. Ich wähle http: // localhost und es funktioniert gut für mich.

für mich war es, weil ich in der Liste "Authorized redirect URIs" https://developers.google.com/oauthplayground/ anstelle von https://developers.google.com/oauthplayground (ohne / am Ende) falsch eingegeben habe.

Jeder, der Schwierigkeiten hat, die URLs für die Weiterleitung in der neuen Konsole festzulegen: APIs & Auth -> Berechtigungsnachweise -> OAuth 2.0-Client-IDs -> Klicken Sie auf den Link, um alle URLs für die Weiterleitung zu finden

Lassen Sie mich die Antwort von @ Bazyl vervollständigen: In der Nachricht, die ich erhielt, wurde der URI "http://localhost:8080/".__ erwähnt (was natürlich eine interne Google-Konfiguration zu sein scheint). Ich habe den autorisierten URI für diesen geändert, "http://localhost:8080/", und die Nachricht wurde nicht mehr angezeigt ... Und das Video wurde hochgeladen ... Die APIS-Dokumentation ist sehr lahm ... Jedes Mal, wenn ich etwas mit Google arbeite apis, ich fühle mich einfach "glücklich", aber es fehlt an guter Dokumentation darüber .... :( Ja, ich habe es funktioniert, aber ich verstehe noch nicht, warum es versagt hat, oder warum es funktioniert hat ... Es gab nur EINEN Platz, um den URI im Web zu bestätigen, und er wurde in der Datei client_secrets.json kopiert ... Ich verstehe nicht, ob es einen DRITTEN Platz gibt, an dem derselbe URI geschrieben werden sollte ... Dokumentation, aber auch das GUI-Design von Google's API ziemlich lahm ... 

Ich musste unter APIs & Services -> Credentials -> Credentials erstellen -> OAuth -> Other eine neue Client-ID erstellen

Dann habe ich client_secret.json mit meinem Befehlszeilenprogramm heruntergeladen und verwendet, das auf meinen Youtube-Account hochgeladen wird. Ich habe versucht, eine Web-App-OAuth-Client-ID zu verwenden, die mir den Umleitungs-URI-Fehler im Browser gab.

Vergessen Sie nicht, den Pfad nach Ihrer Domain und Ihrer IP-Adresse anzugeben. In meinem Fall habe ich vergessen:

/ oauth2callback

Ich hatte zwei Anforderungs-URIs in der Konsole, http: // xxxxx/client/api/spreadsheet/authredirect und http: // localhost . 

Ich habe alle Top-Antworten auf diese Frage ausprobiert und bestätigt, dass keiner von ihnen mein Problem ist.

Ich habe localhost von der Konsole entfernt, meine client_secret.json in meinem Projekt aktualisiert und der Fehler wurde nicht mehr angezeigt.

Sie müssen zu Ihrer Entwicklerkonsole zurückkehren und zu APIs & Auth> Consent Screen gehen. Insbesondere der Produktname.

Versuchen Sie diese Prüfungen durchzuführen:

1. Bündeln Sie die ID in der Konsole und in Ihrer Anwendung. Ich bevorzuge die Set-ID der Anwendung wie folgt: "org.peredovik. $ {PRODUCT_NAME: rfc1034identifier}"
2. Prüfen Sie, ob Sie URL-Typen auf der Registerkarte Info hinzugefügt haben. Geben Sie einfach Ihre Bundle-ID in Bezeichner- und URL-Schemas ein
3. Füllen Sie in der Konsole unter cloud.google.com "APIs & auth" -> "Consent screen" das Formular für Ihre Anwendung aus. "Produktname" ist Pflichtfeld.

Genießen :)

In meinem Fall musste ich den Client-ID-Typ für Webanwendungen/installierte Anwendungen überprüfen.

installierte Anwendungen: http: // localhost [URIs umleiten] In diesem Fall funktioniert localhost einfach

webanwendungen: Sie benötigen einen gültigen Domainnamen [Umleitungs-URIs:]

Ich hatte das gleiche Problem mit der Google-Anmeldung, ich wollte gerade meine Haare ziehen !!! Ich hatte meine Rückrufe korrekt in das Google-Fenster "Berechtigungsnachweis" in der Google-Entwicklerkonsole eingegeben. Es gab meine Weiterleitungs-URLs:

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

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

https://www.example.com/oauth2callback

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

alles scheint gut zu sein, richtig? aber es funktionierte immer noch nicht, bis ich ein weiteres magische urlhinzugefügt habe _ Ich habe anmelden-google url (was standardmäßig google callback ist) ohnewww.) hinzugefügt und Problem gelöst.

Berücksichtigen Sie dies (abhängig von Ihrer Domäne), müssen Sie möglicherweise sowohl mit als auch ohne WWW-URLs hinzufügen. 

Ich hatte das gleiche Problem bei der Autorisierung in der Reactjs-App auf meinem lokalen Computer mit Port 3000.
Ich habe lvh.me in autorisierten Domains und http://lvh.me:3000 für autorisierten Ursprung und autorisierte Weiterleitungs-URL hinzugefügt, wie in den folgenden Abbildungen gezeigt.

Hinweis: Sie können für überprüfte Domains mehrere Sites hinzufügen. i-e für Ihren lokalen Computer, Staging oder andere Umgebungen

Ich hatte dieses Problem mit Meteor und Ngrok beim Versuch, mich bei Google anzumelden. Ich habe die Ngrok-URL als Weiterleitungs-URL in die Google Developer Console eingefügt und bin zur Ngrok-URL-Seite gegangen. Die Sache war, dass ich bei der Ausführung der App nicht Meteors ROOT_URL verwendet habe, also ging jede Weiterleitung zu localhost:3000, der von der Ngrok-URL installiert wurde. Es wurde einfach behoben, indem die Ngrok-URL als ROOT_URL in Meteors Konfiguration hinzugefügt oder exportiert wurde, bevor die App auf dem Terminal ausgeführt wurde. Beispiel: export ROOT_URL=https://my_ngrok_url

Damit es auf localhost funktioniert und wenn es für Webserver verwendet wird, geben Sie es an 

Authorized JavaScript origins (Client ID for web appication)
e.g. http://localhost:4200

Der Trick besteht darin, die richtige Weiterleitungs-URL zum Zeitpunkt der ID-Erstellung einzugeben. Ich habe festgestellt, dass das Aktualisieren der Weiterleitungs-URL, sobald die ID über "Bearbeiten" erstellt wurde, die Aufgabe nicht erledigt. Was für mich auch funktioniert hat, ist das Duplizieren des gesamten 'Vendor'-Ordners und das Kopieren an den gleichen Ort, an dem sich die' Oauth'-Datei befindet (nur bis Sie das Token erfolgreich generiert haben und Sie den doppelten 'Vendor'-Ordner löschen können). Dies liegt daran, dass der Versuch, über '../vendor/autoload' auf den Herstellerordner zu verweisen, für mich nicht funktioniert hat. 

Löschen Sie also Ihre vorhandene problematische Client-OAuth-ID und versuchen Sie es mit diesem Ansatz.

Im Folgenden sind die Gründe für den Fehler "redirect_uri_mismatch" aufgeführt:

1. URL-Feld in Ihrem Google-Projekt leer.
2. Die Weiterleitungs-URL stimmt nicht mit Ihrer Website überein
3. Wichtig! Es funktioniert nur mit Arbeitsdomänen wie example.com, book.com usw. (Nicht mit lokalem Host oder AWS LB-URL)

Empfohlen, Domain-URL zu verwenden

Ich habe Frontend-App und Backend-API.

Von meinem Backend-Server aus habe ich getestet, indem ich auf google api gestoßen bin. Während meiner ganzen Zeit habe ich mich gefragt, warum ich redirect_uri geben muss, da dies nur das Backend ist. Für das Frontend ist es sinnvoll.

Was ich tat, war, einen anderen redirect_uri (obwohl gültig) vom Server zu geben (vorausgesetzt, dies ist nur ein Platzhalter, es muss nur für Google registriert werden), aber meine Frontend-URL, die Token-Code erstellt hat, war anders. Als ich diesen Code in meinen serverseitigen Tests (bei denen der Redirect-URI anders war) übergeben hatte, war ich mit diesem Fehler konfrontiert.

Also mach diesen Fehler nicht. Vergewissern Sie sich, dass Ihr Frontend redirect_uri mit dem Ihres Servers übereinstimmt, da Google ihn zur Überprüfung der Authentizität verwendet.