Fixed in 0.11.1. The handler now resolves both the discovery document and the signing keys through the already-configured OAuth client, so each is fetched once per provider and reused afterwards, and both fetches are asynchronous rather than blocking the event loop. A token carrying no kid header is rejected before any key lookup happens. Upgrading is sufficient, and no configuration change is required.
Root cause
Affected component: the OIDC back-channel logout handler in backend/open_webui/utils/oauth.py, reached through POST /oauth/backchannel-logout. Affected setups: releases 0.9.0 through 0.11.0 with back-channel logout enabled and an OIDC provider configured.
The handler treated its network work as cheap preparation rather than as work worth protecting. For every request it opened a new HTTP session per configured provider to re-read the discovery document, then constructed a fresh JWKS client, whose own cache consequently started empty each time, and asked that client for the signing key through a synchronous call issued directly on the event loop. All of this ran before the token signature was verified, so an attacker unable to produce a valid token still cost the server two network round trips and a blocked loop per request. Both fetches used the library default timeout of five minutes.
Proof of concept
Reproduced by running the unmodified handler from the 0.11.0 and 0.11.1 backends against a loopback identity provider that counted every inbound request and could answer with a configured delay. The submitted token carried a valid issuer and audience, a kid naming a key the provider does not hold, and AAAA as its signature.
60 concurrent requests, provider answering in 150 ms:
Version
Wall time
Discovery fetches
Key-set fetches
Worst event-loop stall
0.11.0
18.6 s
60
120
8255 ms
0.11.1
under 0.01 s
0
0
none measurable
Idle event-loop stall was 10.8 ms in both cases. On 0.11.1 the first request an instance receives warms both caches, and every request after that reaches the signature check without any outbound network call.
Credits
@galanko, for reporting the issue and identifying both the missing caching and the blocking call.