Ktor 3.6.0 adds HTTP/3 on Netty and typed authentication, both experimental

Ktor 3.6.0 shipped on 18 September. The release is led by two experimental features: typed authentication, with specialised support for OpenID Connect, and HTTP/3 on the Netty engine. Alongside them are quality-of-life changes to routing and request handling, and more convenient defaults for Kotlin Multiplatform clients.

What it means

Read the word experimental as the release does: these are APIs you may use and should expect to move. That is the correct trade for HTTP/3, which in most deployments is terminated at the edge by a CDN or load balancer long before it reaches your application — so the interesting question is not whether your framework speaks it, but whether anything in your path does.

Typed authentication is the entry that changes daily code. OpenID Connect handled as a type rather than as a pile of string claims is the difference between a compiler error and a production 401 — and the reason claim handling is a recurring source of bugs is precisely that it has been stringly typed everywhere for a decade.

If you are on 3.5.x, this is a minor-version bump with experimental additions, not a migration. Take the routing and client-default improvements, and adopt the two headline features on a branch.

What "typed authentication" removes

In most Kotlin services today, a token's claims arrive as a map of strings. The code that reads them is a sequence of lookups and casts, each of which can be wrong in a way nothing catches until a request arrives in production with a claim missing, a scope spelled differently, or an issuer that does not match. Typed authentication moves that shape into the type system, where a mismatch is a compile error instead of a 401 with no explanation.

OpenID Connect is the right place to start, because its claim set is standardised and therefore modellable. That is also the limit: a provider's custom claims stay custom, and the typed layer can only be as strict as the spec it encodes.

What to do with an experimental API

Adopt it where the blast radius is one service, not in a shared library ten teams depend on. An experimental API in a library you publish becomes an experimental API in everybody else's build, and you inherit the migration when the signature changes.