auth: relax authentication requirement when hosting on 127.0.0.1

[lightclient]

Alternative to #297. Allows EL clients to expose an unauthenticated Engine API when the host is 127.0.0.1.

For the single-machine setup, it is doubtful whether JWT secret adds any signficant security: from a technical point of view, a socket bound to localhost cannot accept "outside" connections meaning that the only difference is the "filesystem" security - ie processes running as a different user may be thwarted by the additional token exchange, but we have to weigh this against the complexity and failure modes that having a file introduces. The alternative here is that we simply allow connecting without JWT as long as the socket is bound to localhost which achieves the "simple single-machine setup" with less of a hurdle (notably, the engine api is already sitting on a separate port from the "user-level" JSON-RPC interface, so the two live in different "security domains"). --@arnetheduck

--

Currently, if a user wanted casually run a EL and CL on the same host without the aid of any virtualization, it is required that the user specify the --jwt-secret flag for at least one client. Example:

$ geth --sepolia

$ lighthouse beacon --network sepolia --execution-jwt $HOME/.ethereum/sepolia/geth/jwtsecret

I think this is both unnecessary and confusing behavior for users. Ideally, the user should be able to, in any order, bring up an EL and CL and they communicate by default.

The preferred behavior would be:

$ geth --sepolia

$ lighthouse beacon --network sepolia

[holiman]

Another variant is to use a fixed jwt-secret in this scenario. Then the caller still needs to be able to set a custom header, which might raise the bar a bit more.

Then we don't have to worry about webpages doing some sneaky cross-domain POST and bypassing the preflight headers and stuff. I think. Not 100% sure though.