Does that work? We do we get this code when the token expires? Have you tested it? My idea was to do something like this.

# Extract Authorization header
auth = request.headers.get("authorization")

if auth and auth.lower().startswith("bearer "):
    token_str = auth.split(" ", 1)[1]
    user = await get_auth_manager().get_user_from_token(token_str)

    token = get_auth_manager().refresh_token(user.refresh_token)

Thanks a lot for your time! This is not working because the code coming is different. Also, only auth requests end up in this middleware, which makes it impossible to cover each cases. This is a middle state of the code. I tested multiple times. It was really hard and problematic to do this in KeycloakMiddleware. I tried multiple ways in a couple of days this week. Nothing worked because I couldn't properly get the cureent user. I will move the middleware to Core Airlow. I will try to finilise it today or tomorrow.

There is one thing, though I tested multiple times with Keycloak and see that after the token expires internal one, UI automatically calls the login and refreshes the token. I have tested via default to 10 seconds expiration. Without these changes, UI refreshing the token, the only thing is it fallbacks to the home page of Airflow. If we want to fall back to the same page rather than the homepage, that could indeed be done in core Airflow middleware. Of course, if the Keycloak session expires, login is needed. So I am thinking maybe this refresh token is not needed after all. What do you think?

Also, sorry for the delay!

In this concept there are 2 tokens:

• The Airflow token which expiration is set by [api_auth] jwt_expiration_time. When this token expires, Airflow redirects to login page. We do not want to modify this logic
• The Keycloak access token. When a user makes an action through the UI or API, it sends a JWT token. This JWT token is the Airflow token. Airflow deserializes this token and extracts information from it. One piece of information is the Keycloak access_token. Keycloak auth manager then use this access token to communicate with Keycloak server to check whether a user has access to a given resource. This token expires as well and by default it expires every 5 minutes, which means, if a user uses the Keycloak auth manager, after 5 minutes, their Airflow token will still be valid but the Keycloak auth manager will be invalid, which result in every call to Keycloak server failing. This is what we are trying to solve here.

After 5 minutes, we should refresh the Keycloak access token automatically and transparently for the user. This is the purpose of the middleware

Thanks Vincent! Updated the code according to comments.
I have tested and the refresh part is working. The only remaining task is to update the UI to handle this case, as we need to cascade new user information to the UI via the token to retrieve the latest values at a later stage to refresh again. Otherwise, that refresh token expires after the default 5 minutes. Plus, unit tests. Please let me know if there are things that is missed in the meanwhile 🙏

So basically all remains the same. We just expose a "get_refresh_token_url" in the provider, a "refresh_token" in the public API, and we remove the middleware. Then anybody (clients) is free to implement his own refresh flow how he sees fit.

The UI will most likely wait for an "Expired Token" to refresh the token.

Yep I agree with this approach. I think this is indeed better. Thanks Pierre. @bugraoz93 Is everything clear on your side?

All clear, thanks for the discussion and comments! I will follow up with this soon

• Expose an API endpoint
• UI calls the endpoint when the token has expired error is obtained
• Remove middleware
• Call refresh token from exposed endpoint
• Return token to UI, which updates local storage

Bonus could be an additional endpoint to check if the token is valid because this will always be on the auth manager side and will not be directly available to the API without calling an additional endpoint, such as in this case, the Keycloak introspect method. This can tell UI to understand if the token has expired on the backend (not internal JWT). Since this will be available in the auth manager, it is easier to expose to the UI. It would also help automations to understand that their token needs a refresh. Since this will be publicly available, I thought it could be a good addition. What do you think?

I do not think this is needed, we should not check whether the token is valid, we should assume it is and when it is not (catching the exception), kicking off the refresh token flow

Also feel free to split it in two, the backend part, and once we have the endpoints available you can follow up (or someone else) with the front-end refresh token flow. That should make the PR much smaller and easy to review / merge.