Ktor 3.6.0 bringt HTTP/3 auf Netty und typisierte Authentifizierung — beides experimentell

Ktor 3.6.0 ist am 18. September erschienen. Getragen wird der Release von zwei experimentellen Funktionen: typisierte Authentifizierung mit spezialisierter Unterstützung für OpenID Connect und HTTP/3 für die Netty-Engine. Dazu kommen Verbesserungen bei Routing und Request-Handling sowie bequemere Voreinstellungen für Kotlin-Multiplatform-Clients.

Was das bedeutet

Das Wort experimentell ist so zu lesen, wie der Release es meint: APIs, die man benutzen darf und die sich noch bewegen werden. Für HTTP/3 ist das der richtige Handel — in den meisten Installationen endet HTTP/3 ohnehin am Rand, bei CDN oder Load Balancer, lange bevor es die Anwendung erreicht. Die interessante Frage ist also nicht, ob das Framework es spricht, sondern ob irgendetwas auf dem Weg dorthin es tut.

Die typisierte Authentifizierung ist der Eintrag, der den Alltagscode verändert. OpenID Connect als Typ statt als Haufen von String-Claims ist der Unterschied zwischen einem Compilerfehler und einer 401 in Produktion — und dass Claim-Handling seit einem Jahrzehnt eine verlässliche Fehlerquelle ist, liegt genau daran, dass es überall stringbasiert war.

Wer auf 3.5.x ist, bekommt einen Minor-Release mit experimentellen Ergänzungen, keine Migration. Routing- und Client-Verbesserungen mitnehmen, die zwei Schlagzeilen-Features auf einem Branch ausprobieren.

Was „typisierte Authentifizierung" wegnimmt

In den meisten Kotlin-Diensten kommen die Claims eines Tokens heute als Map aus Strings an. Der Code, der sie liest, ist eine Folge von Lookups und Casts, von denen jeder falsch sein kann — und zwar so, dass es nichts auffängt, bis in Produktion eine Anfrage eintrifft, bei der ein Claim fehlt, ein Scope anders geschrieben ist oder ein Issuer nicht passt. Typisierte Authentifizierung verlagert diese Form ins Typsystem, wo eine Abweichung ein Compilerfehler ist und keine 401 ohne Erklärung.

OpenID Connect ist der richtige Anfang, weil sein Claim-Satz standardisiert und damit modellierbar ist. Genau darin liegt auch die Grenze: Die eigenen Claims eines Anbieters bleiben eigene, und die typisierte Schicht kann nur so streng sein wie die Spezifikation, die sie abbildet.

Wie man mit einer experimentellen API umgeht

Dort einsetzen, wo der Radius ein Dienst ist — nicht in einer geteilten Bibliothek, von der zehn Teams abhängen. Eine experimentelle API in einer veröffentlichten Bibliothek wird zur experimentellen API in fremden Builds, und die Migration erbt man mit, sobald sich die Signatur ändert.