Why doesn't the client automatically obtain and refresh JWT tokens?

[KochankovID]

I'm using apache-airflow-client >=3.3.1, <4.0.0 to interact with the Airflow 3 Public REST API.

I've noticed that Configuration exposes username and password fields, but the client doesn't seem to use them to automatically obtain an access token via the authentication endpoint (POST /auth/token).

This is quite confusing and makes the authentication experience unnecessarily complicated.

Expected behavior

When a user configures the client with credentials:

configuration = Configuration(
host=AIRFLOW_URL,
username=USERNAME,
password=PASSWORD,
)

I would expect the client to:

Automatically request an access token from the configured authentication endpoint.

Attach the token as Authorization: Bearer to subsequent API requests.

Automatically refresh or re-acquire the token when it expires.

Retry failed requests when the failure is caused by an expired access token.

Actual behavior

The client doesn't automatically perform this authentication flow. Users have to manually:

Send an HTTP request to /auth/token.

Extract the access_token from the response.

Configure the client with access_token.

Implement token expiration and refresh handling themselves.

This essentially forces every consumer to implement authentication logic outside the official Airflow client.

Questions

What is the intended purpose of username and password in Configuration when using Airflow 3?

Is automatic JWT authentication intentionally unsupported?

Why isn't JWT acquisition and lifecycle management implemented as part of the official client?

Is there an existing recommended way to configure automatic JWT authentication without implementing a custom authentication layer?

[dfbustosus]

Your observation matches the client implementation in 3.3.1 and 3.3.2: supplying Configuration(username=..., password=...) does not perform a JWT login or install a token-refresh flow.

The distinction is visible in the generated configuration code:

1. username / password are HTTP Basic authentication fields. get_basic_auth_token() constructs a Basic header; it does not exchange credentials at /auth/token.
2. The generated Airflow 3 auth settings use access_token. auth_settings() builds the HTTPBearer and OAuth2PasswordBearer entries from that value. The OAuth2PasswordBearer name does not mean the client runs the password-grant flow. With only username/password set, this method returns an empty authentication-settings dictionary.
3. refresh_api_key_hook does not provide a JWT-refresh workaround here. It is invoked by get_api_key_with_prefix(), which this bearer-token path does not call. I checked the same behavior in 3.3.2.

The repository's Getting Started example explicitly obtains the token with a separate helper and then assigns configuration.access_token. Also, Airflow's public API documentation notes that /auth/token is supplied by the configured auth manager, whose documentation defines the authentication details.

So, for these versions, there is no Configuration switch that enables the acquisition → renewal → retry lifecycle you describe. The documented approach is externally acquired tokens; applications needing automatic lifecycle management still need a token-provider/wrapper around that. Updating the access_token on the configuration held by the ApiClient changes subsequent authorization headers, but does not itself fetch a token or retry a failed request.

That establishes the current behavior, not a maintainer decision against ever adding the feature. An auth-manager-aware token-provider API would be a feature request rather than an existing option you have overlooked.