OIDC SSRF protection prevents self-hosted Authentik/Keycloak deployments on private networks
#6,136 建立於 2026年7月16日
倉庫指標
- 星標
- (17,688 顆星)
- PR 合併指標
- (平均合併 14小時 31分鐘) (30 天內合併 314 個 PR)
描述
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.