OIDC SSRF protection prevents self-hosted Authentik/Keycloak deployments on private networks
#6,136 opened on 2026/07/16
Repository metrics
- Stars
- (17,688 個のスター)
- PR merge metrics
- (平均マージ 14h 31m) (30d で 314 merged PRs)
説明
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.