Preflight checklist

• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines."

Describe the issue

Problem

The First-Party OIDC guide uses heimdall's generic authenticator to verify sessions via OAuth2-Proxy's /oauth2/userinfo endpoint. This works for initial authentication but fails to detect when the IdP-side session has been invalidated, because:

1. /oauth2/userinfo does not expose the access token or session TTL, so heimdall cannot perform token introspection against the IdP ([Feature]: Let the userinfo endpoint return more then just a subset of claims from the id token oauth2-proxy/oauth2-proxy#2765)
2. OAuth2-Proxy does not invalidate its own session when token refresh fails with "Session not active" (Stop attempting to refresh access token for session if receiving "Session not active" oauth2-proxy/oauth2-proxy#1945)

The result: the user's session remains valid from heimdall's perspective even after the IdP has revoked it. Configuring cookie_refresh does not help because OAuth2-Proxy keeps retrying the failed refresh without clearing the session.

Suggestion

An alternative approach would be to invert the order: place OAuth2-Proxy in front of heimdall instead of behind it.

User → OAuth2-Proxy (upstream = Heimdall) → Heimdall (proxy mode) → upstream

OAuth2-Proxy runs in standard reverse-proxy mode with --pass-access-token=true, forwarding the actual access token to heimdall. Heimdall can then use oauth2_introspection to verify the token directly against the IdP, independent of OAuth2-Proxy's session state.

This sidesteps both upstream issues. The same pattern also works when integrating with proxies like Traefik or NGINX (OAuth2-Proxy as the forwardAuth target, proxying to heimdall in decision mode, see also #2207).

What do you think about that approach - at least until one of the two issues above is solved?

Version

0.17.9

Additional Context

No response