a.b.localhost redirect URIs in OIDC/OAuth2.0 authentication

[av_vroomly]

When developing a website relying on OIDC/OAuth2.0 login, it is possible without much difficulty to authenticate against a local environment, as long as the local environment has a valid Client ID, much like any other environment.

One can even put restrictions on such a Client ID, restricting the redirect URIs to use it with to something like "https://localhost:8000/accounts/google/login/callback/"

This is all nice and good, and works exactly like one might expect.

Now, you might have a more complex local dev setup, with multiple websites, a reverse-proxy with host-based filetering, etc. For such a situation (and many others), RFC 6761 allows the use of any DNS ending in localhost, and encourages local resolvers to always return loopback queries for such queries (https://www.rfc-editor.org/rfc/rfc6761#section-6.3)

It is nowadays considered good practice to use such domains for local development environments, instead of manually adding entries to local hosts files, making a local network's DNS hijack a (hopefully invalid) TLD, or any other hacky way to get a DNS resolver to return something to use for your local dev environment.

As far as I can tell, all major OS/browsers implement this behavior.

Google OIDC/OAuth2.0 login, however, does not support it.

When authenticating to a redirect URI such as "https://mywebsite.localhost:8000/accounts/google/login/callback/", it returns the following message :

"You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy for keeping apps secure.

You can let the app developer know that this app doesn't comply with one or more Google validation rules.

If you are a developer of [app_name] see error details.

Error 400: invalid_request"

This happens even with an unrestricted OAuth Client ID, and the GCP console refuses such a redirect URI with the following message :

"Invalid Redirect: must end with a public top-level domain (such as .com or .org). Invalid Redirect: must use a domain that is a valid top private domain ."

I'm assuming this is a conscious design choice, but if so, it's puzzling me. Google clearly means to allow developers to be able to login on localhost websites, but then, what reason is there to forbid **.localhost ?

[dionv]

Hello av_vroomly,

There is a discussion in StackOverflow about the same concern, and the workaround I found that suites your concern is from David Callanan:

"This answer applies only to Google OAuth

It is actually very simple and I am surprised it worked for me (I am still sceptical of what my eyes are seeing).

Apparently you can add localhost as a trusted domain on the Google Developer Console, since localhost is an exception for most rules as you can see here.

This can be done on this page under OAuth 2.0 Client IDs. Click edit and then add http://localhost:8000 or similar ports, and hit save.

It is crucial that you include http or https in the input box.

HTTP or HTTPS?

I am once again surprised that Google allows http, although do note that there is a minor security risk if your application has been released to production.

If you want to be extra cautious, you can choose to stick with https. This will require you to set up an SSL certificate on your localhost server.

This is easier than you think, since the SSL certificate needs not be valid. Many http servers should give you this option. You will have to click the "proceed anyway" button anyway in your browser to bypass the big red warning.

This is more secure than http since either a) users will see a big red warning if hackers are trying something phishy, or b) the only time they won't see this warning is if the user intentionally set up a self-hosted SSL certificate, in which case they probably know what they are doing (I suppose a virus could technically do this as well, but at that stage they've already gotten enough control of a user's system to do anything they want)."