AIP-38 Logout

[pierrejeambrun]

Body

Implement the logout flow for the new UI.

• Update the AuthManager interface to expose an optional get_logout_url @vincbeck
• Add a public endpoint to logout that will redirect to the get_logout_url if it exist, similarly to the login endpoint
• Implement le flow front-end (delete the local token and call the /logout endpoint, maybe use an axios interceptor too)

Maybe in a separate issue:

• Handle token invalidation

Committer

• I acknowledge that I am a maintainer/committer of the Apache Airflow project.

[pierrejeambrun]

cc: @vincbeck

[vincbeck]

I came up with a slightly different approach in #47573. I introduced a method logout in the auth manager interface. This needs to be called whenever the user is logging out. I think thi is simpler since we do not have to handle external redirection. Here is the flow:

• User clicks on logout
• Frontend delete JWT token saved in local storage
• Front-end redirect to a new logout route
• This route executes get_authManager().logout()
• Then redirect to login page?

[pierrejeambrun]

cc: @bbovenzi

[bbovenzi]

Yes, we'll need to figure out when we want to automatically log a user out when it isn't authorized. We should make sure we're using 401/403 errors correctly though.

[tirkarthi]

I guess the JWT token is still not invalidated in case of logging out from the frontend which the flask session used to do with session table.

https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens

[pierrejeambrun]

I don't think we do token invalidation. That can be done later (3.1+), I don't think this is required at the moment but a great nice to have indeed.

[tirkarthi]

Could lack of JWT invalidation lead to CVE reports like https://www.cve.org/CVERecord?id=CVE-2023-40273 ?

[pierrejeambrun]

Not really. JWT simplicity is an advantage but also its weakness. By default there is no mechanism to invalidate tokens. That’s up to us to implement additional logic. (Persist invalidated tokens in a table, do a lookup there on auth, maybe clean that lookup table for expired token etc…)

A stolen token, or even after logout, the token will keep being valid until its expiry date. Therefore it’s up to the deployment manager to configure this to a reasonable timedelta. (1 day, 1 hour)

On the other hand, the FabAuthManager uses a session alongside the token (for legacy reason), and this session will be invalidated. (Not the token)

I think this would be nice to have; but I’m not sure this is required for airflow 3. (I could be wrong)

cc: @ash @jedcunningham