StarRocks 4.0.10 accepts JWT login to FE over TLS, but when we switch to an Iceberg REST catalog configured with iceberg.catalog.security = "jwt", Lakekeeper receives the request without an Authorization header and returns 401 Missing Authorization Header. We verified the same human JWT works directly against Lakekeeper, so the likely gap is StarRocks not forwarding the session JWT on REST catalog requests.

Yes, session-JWT forwarding to Iceberg REST catalogs with iceberg.catalog.security = “jwt” is supported in 4.0.10 and is expected to work — including the bugfix backport (#66980) that scopes token forwarding to JWT-only mode. How it works: StarRocks forwards the token in IcebergRESTCatalog.buildContext() only when both are true — security mode is jwt and the session’s authToken is non-empty. Otherwise it sends an empty session context → request goes out with no Authorization header → exactly your 401 Missing Authorization Header. Since security = jwt is set, the gap is almost certainly that the FE session’s authToken is empty. That field is populated only when the FE login itself went through StarRocks’ JWT auth (user created IDENTIFIED WITH authentication_jwt, client sending the JWT as the auth response) — or OAuth2 over HTTP. Plain user/password over TLS does not populate it, even though TLS is on. So “the same human JWT works directly against Lakekeeper” doesn’t mean that token reached StarRocks as the session token — it only forwards a JWT that the FE session was actually authenticated with. To confirm: check that the connecting user is IDENTIFIED WITH authentication_jwt and the client presents the JWT at login (i.e. the session is JWT-authenticated, not just TLS + password). If the login isn’t JWT-based, there’s nothing for StarRocks to forward.

Thanks for the quick reply. Let me test again.