[BUG] restrict is by passed if user connects with token

[battosai30]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

• A client is configured to use this flow :

• A user receives an email with a link including an action-token (for example : email validation, reset credentials ...).
• The user follows the link, he's identified, optionaly confirm his email/set password, and he's logged in.

In case user use the classic form, the restriction works and he get the normal message that he's not allowed to access it.

Expected Behavior

He should not be allowed to logged in.

Steps To Reproduce

No response

Version

- Keycloak: 16.0.0
- This extension: 16.0.0

Anything else?

I'm not an expert on Keycloak so maybe I missed something ... My first idea is that using action token uses another flow but I can't identifie it (and "events" doesn't sho which flow has been used).

Regards

[sventorben]

Hello @battosai30,

I tried to reproduce this with Keycloak 20.0.0 and this extension in version 20.0.0, but no luck.
Could you please give some detailed instructions or provide an example setup to reproduce this?

Thanks
Sven-Torben

[battosai30]

A more detailed scenario :

• A client (Nextcloud in this case) uses the flow I described in my first post.
• A new user goes on Nextcloud => redirection to Keycloak login panel.
• He/she registers him/herself with the standard registration form.
• He/she receives the "confirm email" email.
• He/she follows the link in it.
• He/She is logged in in Nextcloud, even if she/he does'nt have the necessary role.
• He/She logout.
• He/She login.
• Access is forbidden (expected behaviour).
• He/She click on "Forgot password" and follows instructions.
• He/She receives the email to reset password.
• He/she types her/his new password.
• He/She is logged in in Nextcloud.

[battosai30]

I updated KC to V20.0.1 and plugin to 20.0.0 => same issue :s

EDIT : same behaviour with Gitlab client.

[sventorben]

From you detailed descriptions it seems that you are also using the registration flow and credentials reset flow and not only the browser login flow.

Please adapt these flows analogously to the browser login flow. You must add the extension to all flows where you want to restrict access.

[battosai30]

I tried but with similar implementation as the example flow, and the user is denied before being able to change its password

[sventorben]

That's most likely because the Reset password step of the reset credentials flow simply activates the required action UPDATE_PASSWORD for the current authentication session. Since required actions are executed after all authenticators, access is denied by my authenticator before required action will be executed.

Due to this design by Keycloak, I am afraid that I do not really see an option to implement a quick solution, because it would need an additional authenticator and required action.
I have a rough sketch of a solution in this PR. I have a rough sketch of a solution in this PR. I am afraid I a am missing the time to work on this right now.

I can add this as a feature request for a later release.

[battosai30]

Hum ok I understand ^^
As a workaround I will search for a way to avoid changing password does not log in the user (like we see in a lot of solutions : the user changes its password, and it has to login again).