Identity provider login served as 200, not 401 with WWW-Authenticate header

After enabling Cloudflare Access, I noticed that after being 302-redirected to the identify provider (with Instant Auth enabled), the login page for both Google and GitHub are served with a 200-response. The same goes for Cloudflare’s provider landing page when Instant Auth is off.

Shouldn’t these be served as 401, with a WWW-Authenticate header with “Bearer”?

How is a client that tries to reach the origin server’s API endpoints supposed to realize that it hit an auth proxy and needs to present the user with the auth flow (in a webview e.g.)?

For example, the Home Assistant app for iOS tries to connect to the server address given, and expects API replies from a Home Assistant instance. The natural flow would be to present a webview and let the user log in there if an auth challenge was detected, storing the cookie for later requests, until one of them fails again with another auth challenge, etc.

But without any clear way to detect that the response is an auth request it’s effectively indistinguishable from malformed data from the origin server.

What’s the normal way to deal with this?