Implement session_lifetime_minutes or force logout time for Airflow 3 UI

[tirkarthi]

Description

In Airflow 2 session_lifetime_minutes config was present that logs out user when the user is not active for configured value of session_lifetime_minutes . For JWT tokens the expiration time can be set but Airflow 3 UI keeps refreshing after expiration time even with a shorter jwt_expiration_time in airflow.cfg thus user who is once logged in will always be logged in if I understand correctly.

Use case/motivation

This is a requirement in corporate environments to logout after certain time of inactivity for compliance and security.

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

[tirkarthi]

cc: @pierrejeambrun @vincbeck just in case I missed this implementation or an equivalent configuration in auth manager and JWT implementation

[vincbeck]

I have not tested it but as far as I know when the token expire the user should be logged out. That is not the case?

[tirkarthi]

I have set jwt_expiration_time under api_auth as 10 seconds. I see token expiry n refresh on the logs every 10 seconds and the UI doesn't seem to logout. Looks like UI is always renewing the token.

[vincbeck]

Interesting, we should check that out. It should log out

[tirkarthi]

My understanding is that on fab login the session cookie is set to 31 days by default with jwt token expiring on 10 seconds as per my config to test this. So after the jwt token expires the page redirects to login page and the login page which is from fab uses the session cookie sets the user as logged in and goes on to create the jwt token. My understanding is that jwt_expiration_time and PERMANENT_SESSION_LIFETIME should have the same value or less than jwt_expiration_time else the jwt token expires and redirects to login form page which takes the session cookie as current user and logs into the site. So PERMANENT_SESSION_LIFETIME is the setting for actual expiration. PERMANENT_SESSION_LIFETIME used to be configurable in Airflow 2 through webserver.session_lifetime_minutes in airflow.cfg but is no longer possible now. This is only for fab manager and I am seeing the automatic jwt renewal on fab based login.

https://flask.palletsprojects.com/en/latest/config/#PERMANENT_SESSION_LIFETIME

[vincbeck]

You're absolutely right, and thanks for sharing the details. Therefore, the UI logs effectively the user when the token expires but, as you explained, the user gets redirected to the login page which gets re-logged in automatically because the session in still active.

PERMANENT_SESSION_LIFETIME used to be configurable in Airflow 2 through webserver.session_lifetime_minutes in airflow.cfg but is no longer possible now. This is only for fab manager and I am seeing the automatic jwt renewal on fab based login.

Are you sure session_lifetime_minutes used to e configurable in the config? I do not see any references.

[tirkarthi]

Yes, you can use git log -GPERMANENT_SESSION_LIFETIME -p and it was removed from flask app config setup in fab as part of the PR that removed old webserver and Airflow 2 UI.

[zach-overflow]

I'm working on improving our custom Auth Manager implementation (not FAB), and ran into some similar challenges as described in this thread. Namely, the current default logout route logic as of Airflow 3.0.3 will still redirect the user to the login page if the auth manager implementation doesn't override the get_url_logout method.

We've observed this issue as well where the redirect to the login page + our automated login flow negates the prior logout. We were able to fix that by overriding the get_url_logout method so that it redirected to a static HTML page rather than the login page.

However, we've been trying to figure out the best approach for deleting / invalidating the cookie when a user intentionally logs out. Is there an expected / recommended way to handle the token invalidation? I can't seem to find where or how the cookie ends up being stored. Per the current Auth manager doc:

The auth manager needs to save the JWT token in a cookie named _token before redirecting to the Airflow UI. The Airflow UI will then read the cookie, save it and delete the cookie

but I'm not sure where exactly the auth manager ultimately saves the cookie after initially reading it from _token, as that quote implies. Happy to update the doc to clarify this, but I'm not sure what the correct answer is.

[vincbeck]

We've observed this issue as well where the redirect to the login page + our automated login flow negates the prior logout. We were able to fix that by overriding the get_url_logout method so that it redirected to a static HTML page rather than the login page.

The way the log out works in Airflow is. When you click on logout in the UI, Airflow delete the local storage containing the JWT token. Then, the user gets redirected to the logout URL. This Logout endpoint redirects the user to the logout URL provided by the auth manager if provided. If your auth manager uses external resource such as cookie which needs to be invalided during the logout, you then need to create an endpoint on the auth manager side and the user will be redirected to this endpoint on logout. This is how FabAuthManager works. If your auth manager does not provide such endpoint, then the user is simply redirected to the login page.

If your auth manager automatically logs in the user at login (with no form etc), then yes, the logout will look like as though it did not work but since your auth manager automatically logs in your users, I do not know what should be the appropriate behavior?

However, we've been trying to figure out the best approach for deleting / invalidating the cookie when a user intentionally logs out. Is there an expected / recommended way to handle the token invalidation? I can't seem to find where or how the cookie ends up being stored. Per the current Auth manager doc

You mean the cookie handled by Airflow or another cookie your auth manager is using? If it is the former, you should not take care of invalidating the cookie handled by Airflow, Airflow does it itself (unless there is a bug?).

I hope that helps :)

[zach-overflow]

You mean the cookie handled by Airflow or another cookie your auth manager is using? If it is the former, you should not take care of invalidating the cookie handled by Airflow, Airflow does it itself

Ah ok perfect, yes I was referring to specifically the cookie handled by Airflow, and this clarified that for me. Thank you once again for the very helpful reply!

[vincbeck]

Is this issue still relevant or we can close it?