The OAuth provider rejects my callback URL because it points at localhost

Your reasoning is right. The redirect happens in the user's browser, not server to server, so the URL has to be one that browser can reach. localhost means the user's own machine, which is not where your service is.

The fix is to tell the application its public address. Nearly every self-hosted service has a setting for this — variously called the public URL, external URL, base URL or site URL — and the callback is generated from it. Setting it is the whole fix, and applications generate a lot more than callbacks from it: links in emails, absolute URLs in pages, webhook targets. Leaving it wrong produces a long tail of confusing bugs, of which this is the first.

If the service has no such setting, it is deriving the URL from the incoming request, and then this becomes the proxy-header problem: forward the original host and protocol, and make the app trust them.

The requirements the provider is enforcing, so you know what will be accepted:

• Registered in advance. The exact callback URL must be in the provider's application settings, character for character. A trailing slash difference is a rejection.
• HTTPS, for anything not local. This is close to universal now.
• A resolvable public host, since the browser must reach it.

And yes, localhost callbacks are legitimate in one case: an application running on the user's own machine — a desktop app or a command line tool that opens a browser and listens on a loopback port for the redirect. That is a recognised pattern, providers generally allow loopback addresses for it, and many relax the port matching because the tool picks a free port at run time.

What is not legitimate is a server pretending to be that. Your case is a server, so it needs a real address.

One thing to check while you are in there: whether the same public URL setting is also used for webhooks.

Many services register a webhook URL with an external provider using the same base. If it is wrong, the provider's callbacks fail silently and the failure surfaces days later as "some events are missing" rather than as an error.

Setting the public URL once fixes sign-in, links in emails and webhooks together, which is why it is worth finding the setting rather than special-casing the callback.

For development, where you genuinely do not have a public HTTPS address, the options in order of how much I like them:

A tunnelling service. Gives you a public HTTPS URL forwarding to your local port. Register that as the callback and everything behaves as it will in production. Some of them give an unstable hostname on the free tier, which means re-registering the callback constantly — a fixed subdomain is worth paying for if you do this often.

A separate application registration for development, with its own callback, so you are not editing the production one and risking leaving it pointed at a tunnel.

A local domain with a real certificate, mapped in your hosts file. More setup, and it works offline and never expires mid-demo.

What I would avoid is disabling certificate or redirect validation to make it work locally, because that difference between environments is exactly where the bug you ship comes from.