So just recently I decided I would rather use the “Sign-In With Google” feature, rather than trying to recreate a user system on my end. I followed the information on Google’s site to create my client id and then went to work trying to log in.

White List For Authorized JavaScript Origins

It didn’t work, I wasn’t able to log in, and I was confused. The Google pop-up window kept telling me that my server was not configured to send requests. However, checking the white list in my developer console showed that I had added my local machine to the white list.

As it turns out, you cannot use an IP address in the white list; so, rather than using, I had to use https://localhost. Now, that is not listed in the “Authorized JavaScript origins” portion of the OAuth Client set up, but it is mentioned in the “Authorized redirect URIs” portion where it says “Cannot be a public IP.” However, since the instructions for creating a project said that Authorized redirect URIs were not used with JavaScript APIs I didn’t bother reading the small print. As soon as I switched to https://localhost, I was able to log in and get the basic info that I had requested.

Persisting The Logged In User

However, another little issue arose after I successfully logged in on localhost. If I navigated to another page, the Google sign-in button showed that I was no longer signed in. It turns out that for whatever reason, the authentication doesn’t seem to stick with localhost. When I transferred my code to my domain, the log in immediately persisted across pages. So, it seems that Google doesn’t seem to like localhost much fore JavaScript APIs.

Other than those odd bits of info, getting set up with Google sign in was quick and painless.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.