Allow HTTP to localhost on list of redirect URIs for OAuth2 applications

[Aadesh-Baral]

Description

When registering the OAuth2 application, the only non-HTTPS redirect URI allowed is "http://127.0.0.1". When running an application locally, many of them automatically launch on 'localhost'. Because I am limited to using "http://127.0.0.1" as a non-HTTPS redirect URI, this causes a CORS error because my application will be running on localhost and I will be redirected to 127.0.0.1 after OAuth is finished.
As an illustration, while working on Tasking Manager's OAuth2 implementation (hotosm/tasking-manager#5029), which by default begins on localhost, we encountered a CORS error and instructed our developers to restart the application on "127.0.0.1" rather than localhost. Similar problems were faced while upgrading the osm-auth library from OAuth1 to OAuth2.

Screenshots

[tomhughes]

Well localhost is 127.0.0.1 at least on all sane configurations.

I don't really understand what you mean by "launch on localhost" though - you can't bind to a name, only to an address, so even if you give that name on the command line the software will resolve that (probably to 127.0.0.1) and then bind to that address.

[Aadesh-Baral]

Thank you @tomhughes for responding so quickly. Yes, in all sensible systems localhost is 127.0.0.1 but still are different origins.
What I meant by "launch on localhost" is that for example in the case of tasking-manager that uses React frontend, which by default launches on the browser at localhost:3000 when the command "yarn start" is used. Since there are other programs that function similarly, I believe that allowing both "localhost" and "127.0.0.1" as HTTP redirect URIs will be beneficial.

[tomhughes]

Please do not put animated images in tickets - it's incredibly distracting to have things constantly moving on your screen and in this case means I can't even read the error message because it vanishes again after a few seconds!

It also doesn't add anything. I'm perfectly well aware of what the OAuth authentication process looks like - the only useful thing is the image with all the error details.

[Aadesh-Baral]

Removed thanks

[tomhughes]

It might be still be helpful to see the actual error, or possibly the network tab of the debugger or something.

I'm struggling to understand where CORS comes into this? What exactly is the cross origin load that is being rejected?

[Aadesh-Baral]

• My frontend application is running on localhost:3000
• My OAuth2 redirect URI is 127.0.0.1:3000/authorized
• Authorization is done by opening a new popup window after the user clicks on the login button on my application. After authorization is complete user needs to be redirected to the main application tab closing the popup window with the granted code where the code can be exchanged with an access token.

Where I am getting CORS is during redirecting the user to the main application tab after the authorization code is obtained.

[tomhughes]

Right so this isn't really CORS as such - that is where loading a resource is rejected because the resource has a CORS policy that prevents a cross origin load.

What is happening here is that the the popup is successfully redirecting back to the 127.0.0.1 URL but then tries to make a function call on the parent window and that is rejected the parent window has a different origin to the popup at that point.

If you had actually visited http://127.0.0.1:3000/ originally then everything would have worked and this setup (using a popup for the authentication) is tricky in general when there are multiple names for the site because you have to make sure the callback matches the name the user used to access the site.

I think a workaround would be for the callback to reload/redirect to the preferred name before making the function call to the parent - so if the callback knows the application was accessed as localhost but it is loaded as 127.0.0.1 then it reloads to localhost and only then does the function call.

We can consider allowing HTTP to localhost but I need to think if there are any security implications, because there is no guarantee that localhost resolves to a loopback address.

[Aadesh-Baral]

Agree with what you said here

What is happening here is that the popup is successfully redirecting back to the 127.0.0.1 URL but then tries to make a function call on the parent window and that is rejected the parent window has a different origin to the popup at that point.

And sure, everything would have worked if I had gone to http://127.0.0.1:3000/ in the beginning. I believe that allowing localhost would be helpful for developers as this situation only occurs during development.

Thank you for considering allowing HTTP access to localhost.

[pnorman]

Browsers can treat localhost as secure only if they force localhost to resolve to a loopback address.

So there's no guarantee it will be secure, although in practice I believe it is for all currently used browsers.

[tomhughes]

Right but the question is here is whether we allow a callback to http://localhost and we don't know if the browser is going to force that resolution or not.

[Aadesh-Baral]

Hi, @mmd-osm I am using React app with OSM OAuth2 login. I am quite confused what do you mean by Rails port here? I think there is some confusion here. I am not trying to set up the OpenStreetMap website locally.