[potiuk]

For Airflow 3.3+ the Keycloak access and refresh tokens are no longer carried in the signed Airflow JWT — serialize_user deliberately omits them, because Keycloak tokens can exceed the 4k cookie limit — and they travel in separate _access_token / _refresh_token cookies instead.

get_user_from_token validated the Airflow JWT and then attached whatever those cookies contained:

user = cast("KeycloakAuthManagerUser", await super().get_user_from_token(token))
...
if access_token:
    user.access_token = access_token
    user.refresh_token = refresh_token
    return user

Nothing checked that the cookies described the same subject as the JWT. A caller could pair their own Airflow session with another subject's Keycloak token: every authorization decision is sent to Keycloak carrying user.access_token, so the effective privileges are that token's, while get_id() and get_name() — used for the session identity, audit records and logging — remain those of the Airflow JWT.

The fix

The access token's sub is compared against the user id the signed JWT established, before the token is attached.

Both are the Keycloak subject. Every place a KeycloakAuthManagerUser is constructed sets user_id from userinfo["sub"] — the interactive login (routes/login.py), the password grant and the client-credentials grant (services/token.py) — so the comparison is direct rather than a mapping.

A token whose payload cannot be read yields no subject and therefore matches nothing.

On reading the subject unverified

_token_subject decodes the payload without verifying the signature, mirroring the existing _token_expired helper alongside it. That is sufficient for this purpose, and deliberately so:

• the value is only ever compared against an identity the signed Airflow JWT has already established, so it is never trusted on its own;
• a forged token is rejected by Keycloak when it is presented for an authorization decision;
• a genuine token belonging to somebody else is precisely what this comparison exists to catch, and its sub is authentic.

Verifying the Keycloak signature here would add a round trip or key handling on every request without changing which tokens are accepted.

Tests

The two existing tests passed the literal string "access_token" as a cookie value, which carries no subject at all; they now build a JWT-shaped token naming the same subject as the session. Added coverage for a token naming a different subject and for one that cannot be parsed. Reverting the source change fails both new tests.

Local: 290 passed, 1 skipped across the Keycloak provider; ruff and mypy clean.

The provider changelog gains a note at the top, since a session whose cookies disagree will now be refused rather than served.

🤖 Generated with Claude Code