Inloggen via Zitadel faalde vanaf één netwerk, terwijl de route naar huis perfect was. De oorzaak: een DNS-filter die één topleveldomein van mij als verdacht markeerde, en een OIDC-issuer die juist op dat domein stond.

Waarom mijn SSO overal werkte, behalve op kantoor

Mijn homelab gebruikt Zitadel als identity provider. De webinterfaces, waaronder mijn AI-omgeving, loggen in via OpenID Connect. Thuis en onderweg werkte dat, maar vanaf het netwerk van mijn werk niet.

Het onderzoek

TCP naar huis: connect in 0,1 ms. Geen probleem.
TLS-handshake: slaagt, met een geldig certificaat. Geen probleem.
DNS: daar zat het. Voor één van mijn drie domeinen gaf de resolver van het bedrijfsnetwerk een ander IP-adres terug: dat van een blokkadepagina van een securityfilter. De andere twee domeinen resolvden gewoon goed.

De filter had dat ene topleveldomein als verdacht geclassificeerd. Alles onder dat domein werd "vergiftigd", inclusief de OIDC-issuer van Zitadel.

Waarom alleen inloggen faalde

Bij OIDC staat de issuer-URL in elke client-configuratie en in de tokens zelf. De browser moet naar de issuer om in te loggen, en de applicatie controleert of de tokens van die issuer komen. Staat de issuer op een domein dat niet resolvet, dan faalt elke login, ook als de applicatie zelf op een ander, wel bereikbaar domein draait.

De oplossingen

Een bereikbare hostnaam voor de AI-omgeving op een domein dat de filter wel doorlaat. Voor API-gebruik (sleutels in plaats van SSO) is dat genoeg.
Een tijdelijke overbrugging op de laptop: een idempotent script dat een gemarkeerd blok in /etc/hosts beheert, met backup, en dat weigert het blokkade-IP vast te pinnen. Elke naam moet expliciet, want /etc/hosts kent geen wildcards.
De echte fix ligt bij de filter: een whitelist of herclassificatie aanvragen. Een issuer verhuizen is duur, want die zit in elke client.

De les

Bij "werkt hier niet, daar wel" eerst per laag meten: naamresolutie, TCP, TLS, HTTP. Hier zat de fout in de eerste laag, terwijl alles erna perfect was.