Any concerns calling localhost service via web browser?

Question

A bit of architecture here, I want to determine if there is any concern(s) about it.

The interesting part, in diagram below, is the communication between the Local Service and the browser that a user is running. The browser makes requests to the remote service API, but would also do requests to a Local Service (using localhost / 127.0.0.1).

Architecture Overview

The rationale behind this is:

• I don't want to provide a specific UI (or presentation layer) to the Local Service executable.
• Updating web application is easier. Local Service would eventually stabilize and require less and less updates (updates of Local Service would require the user to download a package and install).

Considerations:

• I want to know who is publishing messages to broker by providing a JWT to Local Service, the Web application in browser being authenticated.
• User playing with Local Service API would not be a big concern, it is their data.
• Local port would be something not "assigned" to known services (ex: I would not use 6379, common port for Redis), would be something in the higher range (ie: 20000+)

Two operations would be required between the browser and Local Service:

• Get the status (see if it connects, check if update is required)
• Post the JWT

I have tested this concept, running a local JSON server (the typicode/json-server) offering dummy ressources. Then on the website (using React), a component did a request (using whatever axios, or fetch) to localhost and displayed the data.

The application is related to flight simulation software running on user computer (the Other Application Window in architecture overview). We can communicate via Window Messages (Win32 API) to this application and I made a Local Service that sends AMQP messages. The Local Service is only like a console app without any real user interface and, for a certain user experience, I don't want to bother the user with another UI that could ask for authentication. The idea, is just using a component to send the JWT to localhost.

Here a different architecture view more focused on web application:

Local view

The Component B (or any other component inside web page) is interacting with remote services, fetching ressources, interacting with Identity Provider, etc. This component changes the state (ie: storing the JWT). Component A has access to state and can provide it to Local Service through requests. To summarize, it's not strictly the website accessing the local computer, but a component in browser making requests to localhost. This component has access to 'local' browser state, hence the JWT.

• JimmyJames: Have you tried this? I would expect it to be a pain to get working reliably.
• amon: This is not entirely impossible, but web browsers do their best to prevent access from websites to local resources. To get around this you would have to serve the website from localhost, though that website could then load content from external domains.
• Doc Brown: @athr: clarifications inside comments tend to get overlooked or lost. Please edit your question and give new readers a better understanding of what you are asking. You don't need to do this in a special "edit" section, anyone can see the history of what you wrote earlier.
• athr: @DocBrown Updated
• Doc Brown: @athr: better now, but still hard to read. "The application is related to flight simulation software running" and where is the flight simulator in the diagram? Is it what you call "some process"? "We can communicate via WndProc to this application" - WndProc is a callback mechanism within a process, not an IPC mechanism, so what does that mean? "Local Service that sends AMQP messages." - where does it send them, for what purpose? Instead of this over-abstracting picture which you try to make specific afterwards, why don't focus on a clear description of your specific system?