GitHub user dfbustosus added a comment to the discussion: Why doesn't the client automatically obtain and refresh JWT tokens?
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()`](https://github.com/apache/airflow-client-python/blob/3.3.1/airflow_client/client/configuration.py#L497-L511) constructs a Basic header; it does not exchange credentials at `/auth/token`. 2. **The generated Airflow 3 auth settings use `access_token`.** [`auth_settings()`](https://github.com/apache/airflow-client-python/blob/3.3.1/airflow_client/client/configuration.py#L513-L533) 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()`](https://github.com/apache/airflow-client-python/blob/3.3.1/airflow_client/client/configuration.py#L478-L495), which this bearer-token path does not call. I checked the same behavior in [3.3.2](https://github.com/apache/airflow-client-python/blob/3.3.2/airflow_client/client/configuration.py#L542-L562). The repository's [Getting Started example](https://github.com/apache/airflow-client-python/blob/3.3.1/README.md#getting-started) explicitly obtains the token with a separate helper and then assigns `configuration.access_token`. Also, Airflow's [public API documentation](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html#generate-a-jwt-token) 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. GitHub link: https://github.com/apache/airflow-client-python/discussions/160#discussioncomment-19373991 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
