Require trust sentinel for state.user injection in get_user()

[potiuk]

Summary

The get_user() auth dependency in core_api/security.py accepted any value at request.state.user without verification, returning it before JWT signature/expiry/revocation checks. The only legitimate writer (JWTRefreshMiddleware) is one of many possible middlewares — any plugin or unrelated middleware that wrote request.state.user, accidentally or otherwise, would silently bypass JWT validation.

Fix

Defense-in-depth: introduce a private module-level sentinel USER_INJECTED_BY_TRUSTED_MIDDLEWARE and require it to be set at request.state.user_authenticated_via for get_user() to honour the cached user. JWTRefreshMiddleware now stamps the marker alongside the user. Without the marker, get_user() falls through to fresh JWT validation, so a stray state.user = ... write no longer skips auth.

Threat model

This does not defend against a malicious in-process plugin (which can import the sentinel and set it itself) — plugins are trusted code in Airflow's security model. The goal is preventing accidental writes from unrelated middleware silently bypassing auth, which the audit flagged as an undocumented authentication pathway.

Tests cover both the marked-honoured path and the unmarked-fall-through path; the JWTRefreshMiddleware test asserts the marker is stamped.

Reported by

L3 ASVS sweep — apache/tooling-agents#23 (FINDING-133).

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

[vincbeck]

Does it make it more secure? Any other middleware could also set manually this request.state.user_authenticated_via = USER_INJECTED_BY_TRUSTED_MIDDLEWARE to make it as though it was set by refresh token middleware

[potiuk]

Does it make it more secure? Any other middleware could also set manually this request.state.user_authenticated_via = USER_INJECTED_BY_TRUSTED_MIDDLEWARE to make it as though it was set by refresh token middleware

It's really so called "defense-in-depth" - of somebody adds a middleware that will inject a user, it won't work

So this is not fixing a security issue per se, but makes the architecture more resilient in case deployment manager makes a mistake.

[vincbeck]

I see 👌