The UI container runs a web server to serve up the Javascript code for the UI. Due to the Same-origin policy, Javascript running in the browser cannot make requests to the assisted-service API directly as it is a separate process running on a different port. Instead, the UI code calls back to the UI webserver, which (reverse-)proxies the calls to the assisted-service.

Notably, this means that the only legitimate connections to the assisted-service API come from the UI container or the various installation systemd services, all running on the rendezvous host.

Therefore, we can (and should) enable the same authentication mechanism in the interactive image as we have in the regular agent image. The UI proxy should insert the UserAuthToken authentication headers into requests to the assisted-service API. There is no need for a WatcherAuthToken. The AgentAuthToken should operate as normal.

This is not required for 4.19.

In order to avoid breaking the appliance (which uses the same unconfigured-ignition), we must ensure that when the config-iso is attached it overwrites the UserAuthToken and WatcherAuthToken, effectively switching control from the UI to the config-iso by changing the allowed tokens. The AgentAuthToken must not be updated.