Bypass login flow for already authenticated users?

[sevmonster]

Describe your question
I noticed while setting up links to authentik internal pages that login flows will show even if the user is already authenticated, if you attempt to use /if/flow/login/?next=... directly. Is there a straightforward way to bypass (not deny) a flow completely for users that are already authenticated? I don't want to re-log the user in and/or refresh their session, just bypass the login flow as if they had not visited it and send them to the ?next URI.

If the way to accomplish this with policies etc. is less than trivial then it would be nice to implement this somewhere in stage configuration.

Relevant infos
Here is a use-case. Let's say you want to have a direct link to the authentik sessions page on your site somewhere (/if/user/#/settings;%7B%22page%22%3A%22page-sessions%22%7D). However, because of #3174, if they are redirected to the login flow, this page they visited will be forgotten and they will be redirected to the application dashboard after logging in instead. If there were a way to bypass the login flow for already authenticated users, #3174 would not be a problem, because you could just use the direct login URI (/if/flow/login?next=%2Fif%2Fuser%2F%23%2Fsettings%3B%257B%2522page%2522%253A%2522page-sessions%2522%257D) and be taken to the ?next endpoint immediately if you were already authenticated.

Version and Deployment (please complete the following information):

• authentik version: 2022.6.3
• Deployment: docker-compose

[BeryJu]

related to #3184

[BeryJu]

(I do realise the above PR does not actually fully address the issue)

[sevmonster]

Haven't tried it yet but #3192 should close #2438

[BeryJu]

so the easier way to implement this would be to just make it so that when accessing a flow with the designation of authentication, and already authenticated, you just get redirect to ?next or /, but I don't like adding this kind of implicit special behaviour. With the PR above, a flow can be set to continue on deny, and add a single policy to the flow to deny it when authenticated already (return not request.user.is_authenticated)

[sevmonster]

I agree with your logic. I am testing the PR, the functionality is great and solves a few of my problems. However, should the default be MESSAGE_CONTINUE? I would think MESSAGE should be default so as to match previous functionality, unless this will be a breaking change with 2022.7; MESSAGE_CONTINUE is also generally only useful in a few circumstances.

[BeryJu]

MESSAGE_CONTINUE is actually the default to match the previous behaviour, see https://github.com/goauthentik/authentik/blob/version-2022.6/authentik/flows/views/executor.py#L134 (allthough it might make sense to add this as a breaking change and set it to message)

[sevmonster]

I must have read the source wrong. I'm by no means a Django guy so following the flow of authentik is not so easy for me :)

After checking and migrating all of my flows to a new authentik installation (unrelated to any problems here) I ended up using a mix of the 3 provided options for various uses. This change also gives more power and purpose to the Deny stage, since I had to move some policies out of the flow access policies because them not passing would result in a CONTINUE redirect. In retrospect MESSAGE as default is less important and MESSAGE_CONTINUE makes more sense in my experience.

I was able to get everything to work with all the changes. Thank you.