OIDC SSRF protection prevents self-hosted Authentik/Keycloak deployments on private networks
#6,136 opened on Jul 16, 2026
Repository metrics
- Stars
- (17,688 stars)
- PR merge metrics
- (Avg merge 14h 31m) (314 merged PRs in 30d)
Description
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.