potiuk opened a new pull request, #73306:
URL: https://github.com/apache/airflow/pull/73306
## What
Adds a Security Model section: **Core API session authorisation is resolved
at token issue**.
## Why
The Security Model documents that Execution API tokens issued to workers are
intentionally
not revocable. It says nothing about the Core API session tokens held by
human users, and the
two behave differently.
A Core API JWT resolves authorisation when it is issued. The refresh path
re-resolves the
principal and revalidates the token, but does not re-resolve that
principal's permissions:
- `BaseAuthManager.refresh_user()` returns `None` by default — *"By default,
does nothing"* —
and its docstring notes it is *"called by every single request, it must be
lightweight"*.
- The FAB auth manager does not override it.
So narrowing a user's role does not take effect on a session that is already
running; it takes
effect at token expiry, 86400 seconds by default and configurable.
Revocation is the part that *is* immediate, and that distinction is what the
text was missing.
`get_user_from_token()` checks the token's `jti` against `RevokedToken` on
every request,
including inside `JWTRefreshMiddleware`, so logging the user out withdraws
the session at once
while editing the role does not.
## Background
Written after a security report asked whether the absent re-resolution was a
vulnerability.
Answering it required reading `refresh_token.py`, `core_api/security.py` and
`base_auth_manager.py` and comparing behaviour across two of them. A reader
of the Security
Model should not have to do that to find out where the boundary sits.
The new section states it explicitly, including that reports of a narrowed
role remaining
effective until token expiry are treated as documented behaviour — so the
next such report is
answered by the documentation rather than by a source read.
## Notes for reviewers
- Documentation only; no code change, no newsfragment.
- The claims were checked against `main` rather than inferred:
`refresh_user()` returning `None`,
the absence of a FAB override, and the `jti`/`RevokedToken` check in
`get_user_from_token()`.
- Deliberately kept distinct from the *Execution API tokens not being
revocable* section above
it. That one says worker tokens cannot be revoked at all; this one says
Core API sessions can,
and that revocation is the mechanism with immediate effect. Conflating the
two is what made
the original question hard to answer.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
