potiuk opened a new pull request, #72205:
URL: https://github.com/apache/airflow/pull/72205
`create_client_credentials_token` built a Keycloak client from the
caller-supplied `client_id` and `client_secret`, performed the
`client_credentials` grant, and minted an Airflow session JWT for whichever
service account came back:
```python
client = KeycloakAuthManager.get_keycloak_client(
client_id=client_id,
client_secret=client_secret,
)
```
The route reaching it (`POST /auth/token`) is unauthenticated and there was
no restriction on which `client_id` was acceptable. In a realm shared with
other applications, the credentials of **any** confidential client became valid
Airflow login credentials — not only those of the client Airflow is configured
with.
The `client_id` is now compared against `[keycloak_auth_manager] client_id`
before anything is sent to Keycloak.
Two properties of the rejection are deliberate, and both are covered by
tests:
- **It reuses the response of a failed credential exchange.** A caller
cannot tell "that client id is not the configured one" from "that secret is
wrong", so the endpoint does not become a way to discover which client ids
exist in the realm.
- **It returns before the exchange.** Nothing is sent to Keycloak, so the
endpoint cannot be used to test whether some other client's secret is valid.
**On the tests.** The two existing `client_credentials` tests passed an
arbitrary `client_id` with no configured value present; they now declare one,
which is closer to a real deployment either way. Added a test that another
realm client is refused with no exchange attempted (`assert_not_called` on the
client factory), and one asserting a wrong id and a wrong secret remain
indistinguishable.
Local: 290 passed, 1 skipped across the Keycloak provider; ruff and mypy
clean.
🤖 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]
