feat(console): support proxy user

[creepysta]

The console UI currently supports OAuth2 redirect flows, but only for Identity Providers that support PKCE. This works well for direct authentication scenarios where the UI handles the OAuth2 handshake with the IDP.

Use case

In practice for certain deployment architectures, there's already an central authentication server that handles all user login uniformly. The console UI is deployed behind this central auth layer, fronted by a reverse proxy, with no direct traffic reaching the UI.

In this setup:

• A central auth server handles all authentication
• The UI sits behind a reverse proxy that enforces auth
• The auth header for backend requests is injected by the frontend reverse proxy
• The UI itself does not participate in the OAuth2 flow

For these environments, the UI only needs to know a user info endpoint to extract identity information from the injected headers, instead of initiating its own OAuth2 redirect.

This bypasses both client credentials and the pkce flow where the client doesn't hold the token / user context.

This is similar to how the mcp server is allowed to be configured with _NoneAuthorizationProvider.

This PR exposes configuration options to enable this proxy-auth mode:

VITE_PROXY_AUTH="true"  # "false" (default)
VITE_PROXY_USERINFO_PATH="/oauth2/userinfo"
VITE_PROXY_USER_FIELDS="preferredUsername,user,email"   # since the response body fields may not be standardised
VITE_PROXY_PRINCIPAL_FIELD=""

Flow -

User → [Reverse Proxy (Central Auth) → Console UI → Backend]
              ↑
        Injects auth header

---

Note (further clarification from the email thread)

Ideally the oauth redirect could be handled in the catalog server itself in quarkus layer (as suggested by @snazy), but until that happens we need a way to deal with -

• IdP which doesn't support pkce and supports only OAuth. In this case both client id and client secret is required to perform oAuth redirect (which is not possible to be completely client side)
• Multiple client deployments one per realm, they need the same OAuth credentials (it helps to have a single auth service handling that instead of each deployment managing its own credentials)

As for the purpose of the /userinfo endpoint, its purely to keep it generic. Depending on the oauth proxy, it may not keep the actual jwt in the browser.

[creepysta]

This is similar to the flow described for the mcp server in #197

[creepysta]

@MonkeyCanCode , could you please take a look at this?

[MonkeyCanCode]

Thanks for the contribution. I think it may be better to have @jbonofre to take another look and decide if we wan to move forward with this as he is leading the UI effort.

Going over this feature, here are couple things I am not sure about:

1. Will logout be an no-ops in this proxy mode?
2. Will we get into strange state if somehow proxy failed to refresh token?

[creepysta]

1. Will logout be an no-ops in this proxy mode?
2. Will we get into strange state if somehow proxy failed to refresh token?

1. we can take another parameter (eg; PROXY_LOGOUT_PATH) similar to the userinfo endpoint, and trigger that to perform logout.
2. hmm.. didn't face such an issue so far. Also to note, in the client code I do not see 'refreshToken' being called anywhere today.

[MonkeyCanCode]

1. Will logout be an no-ops in this proxy mode?

2. Will we get into strange state if somehow proxy failed to refresh token?

1. we can take another parameter (eg; PROXY_LOGOUT_PATH) similar to the userinfo endpoint, and trigger that to perform logout.

2. hmm.. didn't face such an issue so far. Also to note, in the client code I do not see 'refreshToken' being called anywhere today.

The refresh is called on Polaris side when using the build-in OAuth. I don't know much about the proxy setup on your end (assuming it will just keep perform login and return back an auth token?), I am more worried about if there are any of such strange state end-users would run into.

[snazy]

I followed up on the earlier Console-in-main discussion.

The core question is whether Quarkus should own the browser authentication/session boundary instead of extending proxy-specific behavior in the static Console. I suggest continuing that architecture discussion on the mailing list rather than duplicating it here.

[rmannibucau]

should be possible to inject a JWT (id_token most of the time, something access_token but can be a convention like reading a cookie or local storage or query param to capture the state since cookie/local storage can be forbidden in some setup) which is assumed validated somehow (proxied app case where auth is handled by the proxy), hitting userinfo is most of the time overkill