OIDC SSRF protection prevents self-hosted Authentik/Keycloak deployments on private networks
#6.136 geöffnet am 16.07.2026
Repository-Metriken
- Stars
- (17.688 Sterne)
- PR-Merge-Metriken
- (Durchschn. Merge 14h 31m) (314 gemergte PRs in 30 T)
Beschreibung
Summary
The recent OIDC SSRF hardening rejects any OIDC issuer whose hostname resolves to an RFC1918/private address.
This breaks legitimate self-hosted deployments where the OIDC provider (Authentik, Keycloak, Zitadel, etc.) is intentionally hosted on an internal network.
Example
Issuer:
https://auth.example.com/application/o/hermes-webui/
DNS:
auth.example.com -> 10.5.5.7
Current behavior:
OIDC SSRF check rejected auth.example.com because it resolved to private address 10.5.5.7
Authentication fails with HTTP 502.
Why this is a problem
In many self-hosted environments:
- Hermes
- Authentik
- Keycloak
all run on the same trusted LAN.
Using private addresses is intentional and recommended.
The current implementation therefore blocks a common deployment topology.
Suggested solution
Keep the current protection by default, but provide an opt-in configuration such as:
webui_oidc:
allow_private_endpoints: true
or alternatively a hostname allowlist.
This preserves the SSRF protection while supporting legitimate self-hosted deployments.