Support Keycloak `Signed JWT - Federated` flow for machine authentication to Airflow

[dlactin]

Description

Today the Keycloak Auth manager supports username/password and client credential authentication to the Airflow API.

I would like to support federated client authentication from external identity providers as detailed here: https://www.keycloak.org/2026/01/federated-client-authentication.

I would also propose a new configuration option that allows a list of valid clients, so not all the keycloak clients in a realm can generate Airflow tokens.

Use case/motivation

I would like to generate temporary Airflow credentials using Keycloaks built in Kubernetes identity provider and a Kubernetes service account.

https://www.keycloak.org/docs/latest/server_admin/index.html#_identity_broker_kubernetes

The goal is to allow API authentication from machines without a user account with static credentials or sharing the airflow client credentials.

We have several external services that interact with the Airflow API from Kubernetes, EC2 instances and other sources that either use static credentials or an in-house application (along with a custom auth provider) to generate a valid JWT.

The keycloak provider looks much more robust and could provide a better machine auth experience.

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[Kunal8954]

I investigated the current Keycloak auth-manager implementation and the federated client authentication flow.
A possible implementation looks like:
add optional client_assertion / client_assertion_type fields to the existing client-credentials token request and forward them to Keycloak;
keep Keycloak as the trust anchor for resolving the federated client identity;
add an optional [keycloak_auth_manager] valid_clients allowlist, defaulting to empty so existing behavior remains unchanged;
enforce the allowlist against the client identity resolved by Keycloak rather than the caller-supplied client_id;
keep existing Airflow-signed JWT issuance and UMA authorization unchanged.
I’d like to confirm the proposed valid_clients semantics/config key with maintainers before implementing it. I’d also validate the resolved client identity against a real Keycloak 26.6+ instance.
If this direction looks appropriate, I’m happy to prepare the implementation and tests.