ウェブサイトhttps://code.google.com/apis/consoleでアプリケーションを登録し、生成されたクライアントID：とクライアントシークレットをアプリに設定して、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 omn​​iauth-google-oauth2を使用しています。

リダイレクトURI（応答が返される場所）はAPIコンソールに登録する必要があります。エラーは、それを実行していないか、正しく実行していないことを示しています。

プロジェクトのコンソールに移動し、API Accessを確認します。あなたの見るべきであるclient IDとclient secretリダイレクトURIのリストと一緒に、そこを。必要なURIがリストにない場合は、[設定の編集]をクリックしてURIをリストに追加します。

編集：（以下の非常に評価の高いコメントから）Google APIコンソールの更新とその変更の存在には時間がかかる場合があることに注意してください。一般に数分だけですが、時々それは長く見えるかもしれません。

私の場合はそれがだったwwwとnon-wwwURL。実際のサイトにはwwwURLがあり、Google Developer Consoleの承認済みリダイレクトURIにはnon-wwwURLがありました。したがって、リダイレクトURIに不一致がありました。Authorized Redirect URIsGoogle Developer ConsoleでwwwURLに更新することで解決しました。

その他の一般的なURIの不一致は次のとおりです。

• 使用http://認定リダイレクトURIの中とhttps://実際のURL、またはその逆として、
• スラッシュを（使用http://example.com/許可リダイレクトURIの中で）およびスラッシュ（末尾使用していないhttp://example.com実際のURLなど）を、またはその逆

Google Developer Consoleの段階的なスクリーンショットは次のとおりです。リダイレクトURIを更新するために開発者コンソールページを見つけるのが困難な場合に役立ちます。

1. https://console.developers.google.comにアクセスします

2. プロジェクトを選択してください

3. メニューアイコンをクリックしてください

4. API Managerメニューをクリック

5. Credentialsメニューをクリックします。そして、下OAuth 2.0 Client IDsにクライアント名が表示されます。私の場合はWeb Client 1です。それをクリックすると、ポップアップが表示され、承認済みのJavaScriptオリジンと承認済みのリダイレクトURIを編集できます。

プロジェクトとクライアントIDの作成に関するGoogleの記事は次のとおりです。

Google+ JavaScriptボタンを使用している場合postmessageは、実際のURIの代わりにを使用する必要があります。Googleのドキュメントに何らかの理由で明確に記載されていないため、これを理解するのにほぼ1日かかりました。

APIなどのクライアント側で認証コードを取得した任意のフローで、コードをサーバーに渡し、コードを引き換えて、アクセストークンと更新トークンを保存する場合は、リテラル文字列を使用する必要があります。redirect_uriの代わりに。GoogleAuth.grantOfflineAccess()postmessage

たとえば、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"}

言及するだけのGoogleドキュメントpostmessageは、この古いGoogle+ログインドキュメントです。G +が閉じているため、スクリーンショットとアーカイブのリンクを次に示します。このリンクはおそらくなくなるでしょう：

Offline Accessのドキュメントページでこれについて言及されていないことは、絶対に許されません。#FacePalm

私のWebアプリケーションについて、私は書くことによって私の間違いを修正しました

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

グーグルもプロトコルをチェックするので、プロトコル「http：//」または「https：//」を必ずチェックしてください。リストに両方のURLを追加することをお勧めします。

これは非常に奇妙で、「1つの」ソリューションが存在しないことを不愉快に思われます。私にとってはhttp：// localhost：8000はうまくいきませんでしたが、http：// localhost：8000 /はうまくいきました。

https://code.google.com/apis/consoleでアプリを登録してクライアントIDを作成すると、1つ以上のリダイレクトURIを指定する機会が得られます。redirect_uri認証URIのパラメーターの値は、それらのいずれかに正確に一致する必要があります。

この回答は、このMikeの回答とJeffの回答と同じで、どちらもクライアント側に設定redirect_uriさpostmessageれています。サーバー側、およびこの構成に適用される特別な状況についてさらに追加したいと思います。

テックスタック

バックエンド

• Python 3.6
• Django 1.11
• Django REST Framework 3.9：APIとしてのサーバー。テンプレートをレンダリングせず、他の場所ではほとんど機能しません。
• Django RESTフレームワークJWT 1.11
• Django RESTソーシャル認証 <2.1

フロントエンド

• React：16.8.3、create-react-appバージョン2.1.5
• react-google-login：5.0.2

「コード」フロー（特にGoogle OAuth2の場合）

概要：React->ソーシャル認証「コード」を要求-> jwtトークンを要求して、独自のバックエンドサーバー/データベースの観点から「ログイン」ステータスを取得します。

1. フロントエンド（React）では、「Googleサインインボタン」を使用responseType="code"して認証コードを取得します。（それはトークンではなく、アクセストークンではありません！）
   • グーグルサインインボタンは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_URIDjango ではsettings.py不要です。（これらはDjango REST Social Authで使用される定数です）つまり、DjangoでリダイレクトURLに関連するものを設定する必要はありません。"redirect_uri": "postmessage"中には、フロントエンドで十分に反応します。これは理にかなっています。なぜなら、あなたがあなたの側でしなければならないソーシャル認証作業は、フロントエンドでのすべてのAjaxスタイルのPOSTリクエストであり、フォームを送信するものではないため、実際にはデフォルトでリダイレクトは発生しません。これが、コード+ JWTフローを使用している場合にリダイレクトURLが役に立たなくなり、サーバー側のリダイレクトURL設定が有効にならない理由です。
4. Django REST Social Authはアカウントの作成を処理します。これは、Googleアカウントのメールアドレス/姓を確認し、データベース内のいずれかのアカウントと一致するかどうかを確認することを意味します。そうでない場合は、正確なメールアドレスと姓を使用して作成されます。ただし、ユーザー名はyouremailprefix717e248c5b924d60メールのようなものになりますyouremailprefix@example.com。ランダムな文字列を追加して一意のユーザー名を作成します。これはデフォルトの動作です。カスタマイズして自由にドキュメントを掘り下げることができると思います。
5. フロントエンドはそのトークンを保存し、バックエンドサーバーへのCRUD、特に作成/削除/更新を実行する必要がある場合、Authorizationヘッダーにトークンを添付してリクエストをバックエンドに送信すると、Djangoバックエンドはそれをログイン、つまり認証済みとして認識しますユーザー。もちろん、トークンの有効期限が切れた場合は、別のリクエストを行ってトークンを更新する必要があります。

なんてこった、6時間以上過ごして、ようやくこれが正解になりました。私がこれを見たのはこれが初めてだとpostmessage思います。Django + DRF + JWT + Social Auth + Reactコンビネーションに取り組んでいる人は間違いなくこれにぶつかります。ここでの回答を除いて、これについて言及している記事はどれも信じられません。ただし、Django + Reactスタックを使用している場合は、この投稿によって時間を大幅に節約できることを願っています。

2015July15-先週、ログイン時にこのスクリプトを使用していたサインイン

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

動作を停止し、エラー400を引き起こし始めました Error: redirect_uri_mismatch

そして詳細セクションで： redirect_uri=storagerelay://...

私は次のように変更して解決しました：

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

チェックリスト：

• httpまたはhttps？
• &または&？
• 末尾のスラッシュ（/）またはオープン？
• (CMD/CTRL)+F、資格情報ページで完全一致を検索します。見つからない場合は、不足しているものを検索します。
• グーグルがそれを更新するまで待ちます。頻繁に変更する場合、またはプールに留まる場合は、30分ごとに発生する可能性があります。私の場合、有効になるまでに30分近くかかりました。

私の場合、私のクレデンシャルアプリケーションタイプは「その他」です。そのためAuthorized redirect URIs、認証情報ページで見つけることができません。アプリケーションの種類：「Webアプリケーション」に表示されるようです。ただし、Download JSONボタンをクリックしてclient_secret.jsonファイルを取得できます。

jsonファイルを開くと、次のようなパラメーターが見つかります"redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]。私はhttp：// localhostを使用することを選択しました。

リダイレクトURLでは大文字と小文字が区別されます。

私の場合、両方を追加しました： http：// localhost：5023 / AuthCallback / IndexAsync http：// localhost：5023 / authcallback / indexasync

上記の解決策はどれも私にとってうまくいきませんでした。下した

承認済みのリダイレクトURLを-https：// localhost：44377 / signin-googleに変更します

これが誰かを助けることを願っています。

/URLの最後の余分な部分と http://localhost:8000は異なることに注意してくださいhttp://localhost:8000/

Railsユーザー（omn​​iauth-google-oauth2ドキュメントから）：

Railsでのredirect_uriのプロトコル不一致の修正

Rails.envに基づいてOmniAuthにfull_hostを設定するだけです。

＃config / initializers / omniauth.rb

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

注意：末尾の「/」は含めないでください

このチュートリアルを使用する場合：https : //developers.google.com/identity/sign-in/web/server-side-flow次に、「postmessage」を使用する必要があります。

GOでは、これにより問題が修正されました。

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

私にとっては、「承認されたリダイレクトURI」リストに（最後に）のhttps://developers.google.com/oauthplayground/代わりに誤って入力したためです。https://developers.google.com/oauthplayground/

@Bazylの答えを完成させましょう：受け取ったメッセージで、彼らはURIを言及しました "http://localhost:8080/" （もちろん、これは内部のgoogle構成のようです）。そのの承認済みURIを変更しましたが "http://localhost:8080/"、メッセージはもう表示されません...そしてビデオがアップロードされました... APISのドキュメントは非常に不完全です... google apiで何かを操作するたびに、私は単に「ラッキー」と感じますが、それについての適切なドキュメントが不足しています。...:(はい、私はそれを機能させましたが、なぜ失敗したのか、なぜ機能したのかまだわかりません...たった1つしかありませんでしたWebでURIを確認する場所であり、client_secrets.jsonにコピーされました...同じURIを記述する必要がある3番目の場所があるかどうかわかりません...ドキュメントだけでなく、グーグルのGUIデザイン

新しいコンソールでリダイレクトURLを設定する場所を見つけるのに苦労している人：API＆Auth-> Credentials-> OAuth 2.0 client IDs->リンクをクリックしてすべてのリダイレクトURLを見つける

APIs＆Services-> Credentials-> Create credentials-> OAuth-> Otherで新しいクライアントIDを作成する必要がありました

次に、client_secret.jsonをダウンロードして、YouTubeアカウントにアップロードしているコマンドラインプログラムと共に使用しました。ブラウザーでリダイレクトURIエラーが発生するWeb App OAuthクライアントIDを使用しようとしました。

次のチェックを行ってください。

1. コンソールとアプリケーションのバンドルID。この「org.peredovik。$ {PRODUCT_NAME：rfc1034identifier}」のようにアプリケーションのバンドルIDを設定したい
2. 情報タブでURLタイプを追加したかどうかを確認します。識別子とURLスキームにバンドルIDを入力し、役割を編集者に設定します
3. cloud.google.comのコンソールで、「APIs＆auth」->「同意画面」のアプリケーションに関するフォームに入力します。「商品名」は必須項目です。

楽しい ：）

私の場合、Webアプリケーション/インストール済みアプリケーションのクライアントIDタイプを確認する必要がありました。

インストールされているアプリケーション：http：// localhost [リダイレクトURI]この場合、localhostは単純に機能します

Webアプリケーション：有効なドメイン名が必要です[リダイレクトURI：]

必要なことは、デベロッパーコンソールに戻り、[APIと認証]> [同意画面]に移動して、必要事項を入力することです。具体的には、製品名。

ドメインとIPの後にパスを含めることを忘れないでください。私の場合、私は忘れていました：

/ oauth2callback

コンソールに2つのリクエストURI、http：// xxxxx / client / api / spreadsheet / authredirectとhttp：// localhostがありました。

私はこの質問に対する上位の回答をすべて試しましたが、どれも私の問題ではないことを確認しました。

コンソールからlocalhostを削除し、プロジェクトのclient_secret.jsonを更新して、不一致エラーを解消しました。

私はグーグルサインインで同じ問題を抱えていました、私は私の髪を引っ張ろうとしていました!!! 私は私のコールバックをグーグル開発者コンソールのグーグル資格証明パネルに正しく入力しましたここに私のリダイレクトURLがあります：

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

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

https://www.example.com/oauth2callback

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

すべてが大丈夫だと思いますか？しかし、wwwを使用せずにsignin-google url（デフォルトのgoogleコールバック）を追加した魔法のURLを1つ追加するまで、問題は解決せず機能しませんでした。

それを考慮に入れてください（ドメインによって異なります）wwwのURLありとなしの両方を追加する必要がある場合とない場合

フロントエンドアプリとバックエンドAPIがあります。

私のバックエンドサーバーから、Google APIを押してテストしていたところ、このエラーに直面していました。redirect_uriこれはバックエンドに過ぎず、フロントエンドにとっては理にかなっているので、私がずっと考えている間、なぜこれを指定する必要があるのか​​と思っていました。

私がやっていたことredirect_uriはサーバーとは異なりますが（有効ですが）、これは単なるプレースホルダーであり、Googleに登録する必要があるだけです）、トークンコードを作成したフロントエンドURLは異なりました。そのため、サーバー側のテスト（redirect-uriが異なる）でこのコードを渡すと、このエラーに直面していました。

したがって、この間違いをしないでください。フロントエンドredirect_uriがサーバーと同じであることを確認してください。Google はそれを使用して信頼性を検証します。

エラーの理由は次のとおりです。redirect_uri_mismatchの問題が発生します。

1. Googleプロジェクトでは、リダイレクトURLフィールドは空白です。
2. リダイレクトURLがサイトと一致しません
3. 重要！example.com、book.comなどの動作するドメインでのみ動作します（ローカルホストまたはAWS LB URLでは動作しません）

ドメインURLの使用を推奨

コツは、IDを作成する時点で正しいリダイレクトURLを入力することです。IDが「編集」で作成された後にリダイレクトURLを更新しても、ジョブが完了しないことがわかりました。私にとってもうまくいったのは、「vendor」フォルダー全体を複製し、それを「oauth」ファイルと同じ場所にコピーすることです（トークンが正常に生成され、重複する「vendor」フォルダーを削除できるまで）。これは、「../ vendor / autoload」を介してベンダーフォルダーをポイントしようとしてもうまくいかなかったためです。

そのため、問題のある既存のクライアントOAuth IDを削除してこのアプローチを試してみてください。