Improve Local Development with localhost callbacks/domains

[Rijnhard Hessel]

Currently when generating API Client Keys you have to have a non-localhost domain and callback URL. 

This makes local testing extremely difficult.

Auth0 for comparison (as an Oauth2 platform) does allow this for exactly this reason.

I do understand that is a security-related measure, so a suggestion does pop to mind:

• Allow Only for "Implementation"/"Development" type environments.

 

Not having this would have a pretty adverse affect for development teams attempting to integrate using this api.

[Lee Savidge]

I would advocate allowing localhost for the callback URL in production. If it were allowed to have web services users to be able to get the access tokens without requiring a user to get them, this would be a useful thing. I wrote an MTD module for another Sage accounting system that required OAuth2 and that connected with the UK Government HMRC gateway and that allows localhost in the callback URL. I use this by creating an HTTP Listener on the localhost and waiting for the response back from the HMRC gateway so I can pick up the tokens. Nothing wrong with it. Making a system so secure and locked down to the point that it becomes unusable is a sure-fire way to make people cut corners or find ways around the problems which causes other issues. It's akin to having such complex password requirements that users either write them down on a post-it, or they just have standard password and increment a number which makes a mockery of the security. There is a trade-off to be made.

[Sterio, Louis]

I tried to make the argument on this with the architects but received strong push back. Response below.

-------

Allowing localhost as a callback URL in production environments can pose significant security risks. Localhost is inherently less secure as it can be more easily targeted by local machine threats, such as malware or unauthorized access by other users on the same machine. This risk is amplified in production environments where sensitive data and operations are involved.

--------

 

As a workaround, developers can use a dummy domain by editing their etc/hosts file. This allows you to enter a redirect URL in the app registry (since we reject localhost) for development and testing purposes.

Here's what you would need to do:

1. Edit the Hosts File:

   • Add an entry in your etc/hosts file to point your dummy domain to localhost.

     Example:

     127.0.0.1 www.mytestpage.com

2. Set Up a Local Web Server with HTTPS:

   • You'll need a local web server that supports HTTPS. You can use a tool like mkcert to create a self-signed SSL certificate.

[Lee Savidge]

@Sterio, Louis I get the response, but isn't modifying the hosts file exactly what any malware would do? If there was malware on the machine that modified the hosts file to redirect localhost, that's exactly what they're trying to mitigate the risk of by blocking localhost as a redirect URL?

Aside from that, let's say I now create a brand new website that sits just for handling token requests so that it is externally available; would that not pose a significantly larger target as it is externally facing rather than the comparatively low risk of allowing localhost which is only visible to the response?

Maybe I could get our network/infrastructure team to set up an externally visible URL which redirects internally to localhost. That could work. I'm not a network expert so I don't know. I will investigate

Edited June 27 by Lee Savidge
.

[Sterio, Louis]

I now have a working example of this locally with no external call back URL. I demonstrated this over our Developer hour: REST API Open Beta session.

I will add the video in the events section by next week.

[Lee Savidge]

@Sterio, Louis Looking forward to seeing that. Thanks for your persistance with this Louis 🙂

It's very much appreciated.

[Sterio, Louis]

1 hour ago, Lee Savidge said:

@Sterio, Louis Looking forward to seeing that. Thanks for your persistance with this Louis 🙂

It's very much appreciated.

The recording has been added, the demo is near the end of the session.

 

Edited July 1 by Sterio, Louis

[Lee Savidge]

I see what you did with the hosts file there. That solves one issue. My other issue is how the tokens are generated to start with. To give an example, I have an application that is hosted on a server open to the internet that provides a number of services to our customers. That application exposes an API via IIS that provides a series of endpoints for our customers if they need these services. For example, one is employee expenses. I have a number of customers that pay to use this functionality. It works via a smart event on the employee expense detail object. It does an HTTP POST when an expense is approved and it then pushes out a load of key/value pairs in the arguments to my endpoint. My application then processes the expense and ultimately creates an AP Invoice in the customer's system. At the moment, for me to enable a new customer I just add the right configuration options on to my application and then create a smart event on the system and it just works from then on.

If this were done via the REST API I would need to generate tokens, which I could do at that point, but I still need to write another application to do that because there is no way for the user to do that. Then what happens if the tokens suddenly don't work for whatever reason? Our support guys will need to regenerate those tokens and then upload them to my application, rather than the application regenerate tokens in the background. If I generate the tokens aren't I granting authority for my application to work rather than the customer granting authority? I thought the idea of OAuth is that the onus is on the customer to do the granting without us knowing their details.

Because of the nature of the smart events -> HTTP POST, there is no way to pop up a screen to the user for them to grant my application authority and get tokens, or generate new tokens which makes using smart events -> HTTP POST cumbersome with OAuth.

[Lee Savidge]

To be fair, I think my last comment is going off topic but I couldn't delete it or even edit it.